we have a production site like www.Domain1.com, and developing a new web application www.domain2.com, and would like to implement single sign on.
I am looking for solution pretty much like how google works like login to gmail, in gmail navigate to other google apps or we can open new window and we can use picasa or other google apps with out login.
I have found an interesting solution, where we will be developing a dedicated Authentication site like www.sso.com.
http://www.codeproject.com/KB/aspnet/CrossDomainSSOExample.aspx
we use webfarm environment, site 1 and site 2 will be deployed in webfarm environment, but when we deploy www.sso.com in webfarm , this solution will not work.
I am sure google might have implemented www.sso.com service in webfarm environment. i am trying to understand and implement the same.
Experts i kindly request your help in this direction , any information which helps me.
AFAIK, after Google authenticates user with main auth site/service, it issues a set of redirects to auth. end-points to all main domains with one-time secret key in URL, so each end-point on each domain sets auth. cookies for given user.
E.g. user signs in at http://sso.com/login, then he is redirected to
http://domain1.com/auth?secret=12345
http://domain2.com/auth?secret=12345
...
http://domainX.com/auth?secret=12345
And each domain sets an auth cookie to the browser.
Correct me if I'm wrong.
Related
Never thought I'd run into an issue of having too much documentation! I need help with picking the right information so I can read it, understand it, and follow it.
My scenario:
I have an ASP .NET Web Application that is hosted on mywebapp.azurewebsites.net
The web app has a full REST API at mywebapp.azurewebsites.net/api/v1/dostuff/1
You can go to the site and perform all the CRUD stuff. You can also use desktop application to do the same.
I went ahead and enabled Azure AD authentication in Azure Portal. Now in order to do anything on the website, users need to sign in. It brings up the usual Microsoft Login popup and then upon successful authentication redirects back to the site.
But when it comes to the desktop app, I want the users to be able to use it without signing in. Somehow my desktop application needs to be able to make calls to the API/website and be authenticated!
At this point I am lost if there is something I need to do in manifest file, or in the web app, or elsewhere?
Most I was able to do is get an access token using client credentials/client secret.
I just need to know if what I am trying to achieve possible and which document explains the approach of doing so.
Well the fundamental problem you have is that a desktop app (like any public client) has no way of authenticating itself to AAD in a secure way.
You cannot use a client secret.
It is very easy to grab the secret from the executable, and that is basically your app's password.
You would have to make the API accept calls without authentication pretty much.
If authentication is required for access to the API,
then a user must authenticate in the app.
For multiple applications, I want to build a centralized account solution. The core consists of some ASP.NET Core web applications. But I also want to include third-party applications like WordPress, GitLab, or a XAMPP/HipChat server. My goal: The user creates ONE account, which can be used in all of those applications. So an LDAP server seems the best way for this since many applications have support for this protocol. This also gives flexibility for other applications, which may be added later.
The problem here is, that the users should be able to authenticate using common social sites - Especially Facebook. It's state of the art and would increase the conversation rate, cause it's easier for the users.
Is it possible to integrate social login provider like Facebook to LDAP servers like ApacheDS?
As I see the topic, Facebook generates some kind of authentication token, which can be used from the application to verify the identity of the user. In my custom web apps, this is no problem. But for e.g. a XAMPP server, this seems not to work: LDAP requires username/password. But I don't have this, since there is only a Facebook token available. The LDAP server could store this in an attribute. However, this would require to check this token instead of a password on an LDAP bind.
On the other side, when I drop the LDAP server and use some framework like ASP.NET Core identity instead, it's not a big deal. The problem here: I'm not able to use this login for third-party applications. This would require the users to have an additional account for e.g. XAMPP, WordPress, and so on, which results in big chaos and is thereby not suitable for me.
By dropping social support, it works. This seems also not to be a good idea since those logins are state of the art and I'm targeting younger users, which expect an SSO solution with Facebook or similar providers.
Facebook (and other social login sites) use a protocol named OAuth to authenticate. Probably the easiest solution would be to implement an OAuth server yourself that uses your LDAP as backend and then add that beneath the Facebook login as the second way of login.
That will not add users logging in via Facebook to your LDAP but as you usually only get an OAuth token back for login (not necessarily a username) which needs to be verified against Facebook (or whoever provided that token) it doesn't work to use it as "password replacement".
How to prevent someone just taking my API keys from the client side javascript code and starting to use my HERE subscription for some other use.
I noticed HERE provide an option to secure the API keys for a certain domain on the applications management page: "Secure app credentials against a specific domain". I have set up this option and also put domain there but I do not see any change on my app behavior.
The application still continue working fine on my PC. Shouldn't the HERE API stop working as web server is running on localhost and not on the defined domain.
My app is running fully on browser, and only static files come from the server (http://localhost:8083/index.html). I am using the HERE javascript API.
I tested also running the app on external cloud service on different domain than localhost. Results are the same. My conclusion is that the setting "Secure app credentials against a specific domain" just has no impact and does not work. Checked also the api response headers and all origins are accepted.
Access-Control-Allow-Origin: *
In your HERE dashboard, you can set the application id and application code to only work on a particular domain or set of domains. If the tokens are fixed to a domain, it won't matter if someone takes your tokens because only the listed domains can use them. If you don't secure the tokens to a domain, then someone will be able to use your tokens if they find them.
I'd like to use OpenID to authenticate users on my webapp -- similar to how StackExchange does it. I'd also like to enable users of my website to use my Desktop and Mobile Apps using the same account. I've read this requires OAuth (OpenID is purely website only).
What I don't know is
Is this the correct approach?
What would the workflow for this be?
What data do I need in my database per user/OpenID? Do I store an "account" and then when they've authenticated with OpenID, I allow them to generate an OAuth Token for the mobile app?
In an ideal world, I would be able to have buttons similar to those on https://stackoverflow.com/users/login for both my WebApp and also in my Desktop and Mobile Apps which would simply allow users to login with their google or facebook account, is that possible? Simplicity for users is paramount, because my userbase will not take well anything remotely complex.
Can I use something like DotNetOpenAuth to provide all of this functionality?
Would a better solution be to break this up and allow users to authenticate to my site with OpenID and then I provide my own OAuth scheme for my desktop and mobile clients?
Probably the simplest mechanism is to embed a web view, and simply watch for navigation to a specific callback page and grab the authentication data that way. You should still be able to use OpenID for this.
What you should be looking into is Windows Identity Framework (WIF), it will work similarly for Web or Desktop applications using Claims-Based Identity. You would store an authorization token for each user (along with any other information you need) and you would get it in the Authorization Header of an authenticated HTTP Request. oAuth is the protocol for passing authorization requests and responses. WIF is a .NET toolkit to simplify this interaction.
For more info, check out the WIF home page and the following blog (not mine):
http://msdn.microsoft.com/en-us/security/aa570351
http://blogs.msdn.com/b/vbertocci/
This is the workflow that I came up with, and so far I think its working well.
The user is required to authenticate to the website via third party OpenID/Facebook/etc (mobile friendly website is available). Then, in their "profile" they can generate an API "key" which they can copy/paste into their client software. It isn't 100% transparent to the user, but its pretty good.
I am trying to implement OpenId for an internal web app. Our college is on Google Apps for Edu, so we have the suite of Google OpenID and OAuth exposed to us.
I would like my login page to have the standard username and password, and additionally a button on the side that will authenticate internal users to our app domain.
I have followed the example here http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/ but it seems that the rules are different for the google apps id than a general google id.
Any help or further documentation would be helpful.
I have the same problem as you.
For your Google Apps login, your relying party URL is https://www.google.com/accounts/o8/site-xrds?hd=example.comsite-xrds?hd=example.com
Where you replace example.com with your URL.
However, As far as I can tell, dotnetopenauth does not handle the protocol extensions google uses when it returns.
However, using https://www.google.com/accounts/o8/id works perfectly fine.
Using this url, you pass off users to Google to login. Google will check for cookies and prompt for a login if required. if not it'll just confirm with the user that they want to associate their authentication with this site and pass you back.
Still trying to get dotnetopenauth to accept the new url: https://www.google.com/accounts/o8/site-xrds?hd=example.com