What is the best/proper technique to share login between two sites.
I have website A, and some websites B. Both types belong to the same company, but B is running on the customer premises. What I would like, is that users login in B, and when redirected to A for some reason, they don't need to login again, and they can work with their account in A.
Of course, the company will make logins for each 'B' user. The problem is that the user could initiate the login in A or B.
Would OAuth do? Or OpenID would be more suitable?
Another option is pass a GUID token in the GET string, with a sort time to live and only valid for the IP address of the requester, but it is not sure the user would access the web sites through the same gateway.
Thanks
OAuth is exactly what you need. OpenID offers discovery which is only useful when the user gets to choose who to authenticate with (not your use case). Also, OpenID is much more complicated and is a dying protocol.
In your scenario, Server A is the OAuth server (or authorization server in OAuth 2.0) and Server B is the client. There are many ways to implement this, but I would suggest you start by looking (and trying) how Facebook OAuth 2.0 implementation works. It will give you a good idea of what is involved and some of their extension (e.g. display) which make it more user-friendly.
You are talking about single sign-on. Does the company who owns Website A provide remote sign-on in their api?
You need to make sure that the log-on information is encrypted when it is passed to website A. The last single sign-on I built required me to pass the user's AD name encrytped via RSA and hashed with MD5. The third party had a database of the user's AD name and their password to the third party site. When the user clicked a link, their encrypted information was sent to the log-on api of the third party and the third party redirected them to the welcome page with the log on process complete.
If you are building a single sign-on API yourself, as in you have control over website A, OAuth is a respectable choice. It is fairly easy to impliment.
Related
I have an Angular Single Page Application (SPA) talking to my ASP.NET API.
The API is protected by my own Oauth2 server (IdentityServer4).
One of my customers (let's call him X) wants SSO: Their users on my platform would sign in on their server instead of using the login form in my app that connects to my IdentityServer.
Each customer has its own subdomain for the Angular SPA (e.g. x.myapp.com). Therefore I can easily redirect X's users to their server's authorization page to approve my API, based on the hostname.
However the API itself uses one common hostname for all customers(api.myapp.com). Customers are distinguished by the Origin header of the API call (x.myapp.com) during the login call (and a few other unprotected calls) and by the Bearer token for protected calls to the API.
How does my API introspect the Bearer access token? Who should know which server to query ?
Is it the responsibility of the API server? Or can I tell my IdentityServer about X's oauth2 server ?
X's users would also be defined on my platform since we need specific info (such as config of roles on the platform). My current setup implies specific claims (such as user id) that allow my API to know what the user can do. Obviously, X's server will not provide the same claims. How can I connect the dots ? e.g. get some standard claim from X's server (username, email, whatever) and match it to my list of users.
Note: This question is similar but the answer is not accepted and seems to imply that the provider of both identity servers is the same (not the case here).
Formatting my comments as an answer:
From reading your question it's pretty much clear to me that you could benefit from what is know as Federated identity.
As you said, one of your customer want to achieve SSO - They want users to login using their existing accounts and be able to user your systems normally.
Since you already have an IdentityServer in your domain, what you can do is delegate the login part to the customer's side (whatever they do it). This is illustrated in the Identity server documentation Federation Gateway.
Basically, the approach is that upon hitting the "login" button in your front-end, you would redirect the users to your Identity Server passing some special params (prompt and acr_values for ex) which in turn, tells identity server to redirect the user's to the external Identity provider (the customer's). After a successful login, you have a chance in Identity Server to augment the claims, maybe using something they returned or anything really. Then the process is as normal - you return a JWT Token generated by your Identity Server
The benefit of doing this is:
Your SPA/API doesn't have to change. You will still work with your own bearer tokens and can continue doing authN/AuthZ as before.
You have a chance to add claims that might indicate where this user is coming from if needed
If your customer's server changes, you don't have to worry much, apart from maybe some tweaks related to returned claims
They don't necessarily need to use OpenId/OAuth on their side for this to work
Useful things you probably will need is some params to pass during the call to the authorize endpoint in Identity Server. (acr_values and prompt).
You can also check this in the quickstarts, by looking at Sign-in with external providers (which is pretty similar to what you want)
Now to your individual points:
Your Identity Server should be the "bridge" between you and the customer's "identity provider".
Upon a login from an external provider (X), you need to somehow identify the user on your platform. You could use email or, even better, if X is already using OpenId/OAuth they might give you the sub claim which is the user id on their side. At this point you need some sort of agreement with them otherwise this might be flaky/unreliable for both sides.
In a more "advanced note" you could also add to your tokens some sort of claim that tells you who is the source provider of this user. Here the source provider would be X. This is useful because you might want, for example, configure allowed identity providers in your app, or maybe enable features only for certain providers. Like, ppl logging in with Google might only see certain parts of the app.
We are building several websites/products, if a user has an account on one site they will also be allowed access to all other sites.
Let's say we have the following setup:
Clients
site1.com
site2.com
Single Sign On Portal
sso.company.com
APIs
api1.company.com
api2.company.com
The Single Sign On Portal supports multiple OAuth providers, such as Google, Microsoft, Facebook, etc and this is all working great built on top of the default ASP.NET Web Forms template in VS 2015 using OWIN and Idenity.
The SSO site is logging the user in an using a cookie for authentication, which works fine while still on the SSO site. Now we need to return a token that the client site can use to know that the user is authenticated
Now the challange here is how do we exchange the cookie to a token that we can return to the client(s) to use in the Authorization header in request sent to our APIs?
Should we generate a token our selves or is there some built in functionality we can use for this purpose?
I've seen most people generate a token themselves and then multiple accounts can be linked to that same user in your account (i.e. a user could log into both FB and Google). Most of the SSO providers have a way to get an identity token or one time use code for your server to use and get user info like FacebookId. The key is ensuring that identity token came from FB and not a third party.
Auth0 is a pretty good service if you want a managed route. Even if you don't use them, they have a lot of good resources on oauth. (I have no affiliation with them other than that we used them before.) we also have a little more info on auth: https://www.moesif.com/blog/technical/restful-apis/Authorization-on-RESTful-APIs/
Am pretty new to ADFS. We have a requirement of enabling SSO between our application (A) and Client application (B).
B is configured to authenticate against ADFS. We need to integrate A with B and enable SSO. User will always login from B and will have link to A. When user clicks on link, he should be navigated to page in A. We want the authentication mechanism to A via a centralized module (may be service).
I have 2 questions.
1. if we get relevant information from client ADFS like Relying party Id,ADFS endpoint and Certificate details to implement a service that will take care of passing claims to our application A, is it possible.
Once the user cliks on link in B, how do we get the claims in A if A is not "Hardcoded" configured with client's ADFS.
Kindly guide.
There are multiple ways:
both A and B are federated with your ADFS and use ws-fed, thus navigating to A from B involves ADFS but this happens quickly and without user interaction
B acts as a Relying STS so that A authenticates in B using ws-fed. This is difficult if you haven't done this before
B passes user credentials to A using yet another, completely custom way. One of our apps (your B) shows a qr-code that another app (your A) scans and uses the qr encoded one-time guid to ask B directly on whom the guid belongs to
My recommendation is the first way and the last if first is not applicable.
We have a hosted .NET web application (Windows Server 2012 R2 environment) and we need to provide Single sign-on (SSO) to users from a corporate LAN environment. We have used ADFS to enable SSO and it is working as expected thus when a user hits our web application login page URL he is authenticated against ADFS and is automatically logged in to the application.
We have an additional requirement where we need to obtain a list of all users, their groups, email addresses some additional information periodically from their Active Directory so that this information can be bulk loaded into our web application however since ADFS is implemented we do not have direct access to the Active Directory.
Is it possible to connect to ADFS and obtain a list of all users, their email addresses etc. programmatically?
If the above is not possible then what is the recommended approach for this kind of a setup?
Thank you.
No, this is not possible. There is no such API because with SAML and WS-Federation, users can come from anywhere. This does not have to be AD, technically it's possible create a "Log in with Facebook" implementation.
What would you need the information for? The user's claims contain all information which you might need (user name, e-mail address, group memberships).
If you really need that information about all users in your application, perhaps ADFS is not the solution you are looking for.
As Alex mentioned above - the way it works, ADFS does not provide any way of importing data from the AD or other trust stores. It just gives you the information that are carried over with the token.
In case you need more information, you should extend the number of claims being issued by ADFS. You can then collect the information - when the user comes for the first time, use the data from the token and fill the profile. If it is returning user - update the information if necessary.
The other solution (but I wouldn't say it's recommended - rather a workaround) would be to implement custom solution for importing information from AD to your application. I'd say it's fair as long as you use your local AD for reading this data. In the moment you decide to extend the access to third party (e.g. partner company), which might be using different identity provider, which doesn't have to be backed by Active Directory any more - you find yourself in tough spot.
We are running a Saas ASP.NET 3.5 Web application using Forms authentication on a IIS 7.5 public server with protected content for thousands of users. We also have some subapplications running ASP.NET MVC 2.
Usernames and passwords are stored in our database and every user has roles and groups attached, with privileges and access rights defined.
Now we have been asked to also facilitate for simple SSO login via Active Directory so that users do not have to enter username and passwords twice to login. These users will originate from different networks and domains.
No user "sync" should take place from our servers to LDAP serves. We are not sure that any communication with LDAP is needed since all users will be created in our system and maintained there. Forms authentication will be used for most of our users.
From here on we are unsure which is the best path to choose. For our scenario what would be the "best practice" way to proceed?
The simple answer is SAML. It is considered the "best practice" and many large SAAS providers support it.
SAML protocol defines the single sign on flow between multiple systems. It establishes trust between systems using certificates. Your application accepts an assertion containing attributes (user id, name, email address, etc.) from other systems. Your app will map the user into your user store.
In .NET world there are several options. You can find a library that implements SAML (ComponentSpace has one) and hook it into ASP.NET authentication. You can create your own using Windows Identify Framework (WIF). Here's the boatload of WIF videos http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/. You can try IdentityServer http://thinktecture.github.io/
Depending on how secure your app must be, you can opt for a simple option of passing user id from trusted networks using a simplified method. I've seen apps that allow user id to be sent via URL parameter or form field. Of course, this is horribly insecure, and you are taking on more risk, because the trust between two networks is not cryptographically enforced. You can mitigate it somewhat by checking referrer string or IP address (if you can isolate IP range of a corporate network for example). But you are still open to spoofing because any user can impersonate others by simply replacing user id within HTTP request.
It probably doesn't answer your question fully, but hopefully points you in the right direction.
I recommend looking into ADFS 2.0 it is very powerful in terms of claims mapping and works with AD: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
What you would make is a token consuming portion of your app that would receive and parse the final claims returned to your web server after the authentication loop.