I am trying to find out how to set up 2 separate versions of ADFS, one as the RP and the other as the IP.
We have 2 websites both protected by 2 different ADFS implementations.
I need to set up one ADFS to trust the other so that the users in one can have a Single sign on experience across both applications.
This seems like it should be a popular configuration but all of the information I can find uses some other type of IP, either ACS, or some other brand STS.
For two ADFS say A (IP) and B (RP).
A has a website X.
B has a website Y.
Set A up as claims provider trust to B
Set B up as a RP for A.
A has an RP which is X application.
B has an RP which is Y application.
So A has two RP.
To set this up, in the ADFS wizard for B, select "Add Claims Provider Trust" and user A's metadata.
In the ADFS wizard for A, select "Add Relying Party Trust" and user B's metadata.
Related
I have a SaaS application that has multiple organisations and each organisation has multiple users. Each customer is an organisation (not a user) and the customer wants access to their data in my SaaS application via API. Obviously I need to authenticate the customer so they only receive the data that belongs to their organisation.
The customer will be importing this data from their application so this is a server-to-server API call which I assume I need to use client credentials flow.
The customer will be able to generate the credentials on a self-service basis.
Is using client credentials flow the correct flow?
If using client credentials flow does each customer have their own client_id and client_secret or does my application have 1 client_id and each customer have their own client_secret?
The standard solution for this type of B2B API solution is to use Client Credentials flow as you suggest.
Each business parter uses their own client id for identification when calling your API
Each partner is also given a string client secret - though it may be possible if your authorization server supports it to use secrets based on an X509 credential
Use of different client ids enables you to turn off Partner A without impacting PArtner B - and also to tell callers apart
Authentication completes based on the client id and secret being verified and you then move onto authorization. Typically your API will need to continue by doing this:
Receive a technical client id such as 08134scdv79
Map it to an application specific id, such as a primary key from your Partners database table
Authorize the request based on whether the caller is allowed to get the data requested
The one interesting aspect to your question is the self service part. I assume you mean some kind of administrator from a business partner can set up credentials - but that this remains a restricted operation?
I am starting to design Multi-tenant system and already read the article:
http://msdn.microsoft.com/en-us/library/aa479086.aspx
Any case, I have couple of question related to authentication.
For example, we need to support a customer that requires Separate Databases.
More precisely, the customer uses Separate LDAPs (LDAP per tenant).
The problem I can not solve that the authentication framework need to know a tenant before the authentication to authenticate against the appropriate LDAP.
How a user selects tenant during the authentication?
The form authentication:
Should we develop a special form login with 3 input fields: user name, password, and tenant?
Should we show to a user the list of all tenants?
This is information disclosure, a user can see the list of all tenants in the deployment.
Should it be free text filed? In this case it is error prone.
Other types of the authentications:
How tenant information can be send if we use Basic Authentication? Digest Authentication? Client Certificate Authentication?
Any point to already existing(free) frameworks will be appreciated.
As you correctly mentioned, You have to identify the Client/Tenant ID while you allow the user to login to the multi tenant application. There are basically 3 ways to identify the Tenant ID.
use company code text field where your users can enter their tenant id,password/username to authenticate (Error prone, users may not enter the id correctly).
collect the username and password and identify the Tenant ID by yourself, but you have enforce Unique identity (email) for all the users in the system. (Preferred)
Assign unique Sub-domain for each tenant (Preferred). using unique url of the customers, you can identify the tenant id and you can connect to appropriate DBs of the customer.
WRT to Authentication, I personally don't recommend Basic Authentication because of the security vulnerability, So you could either go with Digest Authentication/ Client Certificate Authentication.
I have to create a way to keep the session authentication from application A to application B, but I can´t use:
SSO
POST calls
and, we know that GET is not a good choice, but I´ll need to use it. So, I think to use something like "public keys", what you think about this approach?
I think in:
User do authentication in application A.
Into application A, have a link to application B; User click on this link
Application A open application B page sending a "public key" (database persistent authentication key?)
Application B validate this key and authorize or not the user.
In step 3, rather than thinking of a "public key", think of a "session token". Specifically, A redirects to B with
http://b.application.com?token=123-3-2-1-3-2-2-1-2-32-3-5-2-4-5245
Tokens should be unique and short-living.
B then contacts A directly and asks about the identity behind the session token:
http://a.application.com/userservice/getuser/123-3-2-1-3-2-2-1-2-32-3-5-2-4-5245
Because B contacts A directly, there is no way for users to forge invalid tokens - a random token just points to non-existing session at A.
In an ASP.NET MVC 4 application using the .NET 4.5 framework in conjunction with Azure Access Control Service (ACS), I want to provide the users multiple authentication possibilities (i.e. Google, Facebook, Windows Live, etc.). What is the "best practice" for associating a single user to multiple identity providers?
For example, say the user logs in with Google one day, then goes to another browser the next day and logs in with Facebook. How would I know to associate the Facebook login with the previous Google login to the same user?
Look no further than stackoverflow itself for a good example of this. Click your user profile and then select "my logins".
When a user creates their account, they select which identity provider you want to use to sign in. Under the hood, your application creates a new site-specific unique user ID, and links it with a 3rd party provided unique ID. (You might use email, but most identity providers will also provide a unique user ID claim that doesn't change, even if the user changes their email)
Now, after the user has signed in, they have an account management control panel through which they can establish additional links to other identity providers.
I see two options for achieving this:
Have your MVC application persist account links. When a user signs in, you query your account link store using the 3rd party unique ID claim and resolve your site specific unique user ID.
Use the ACS rules engine. You would create one rule per account link. For example, lets say I can sign in with either gmail or liveid and my unique id is 1234. Two rules look like this:
google + me#gmail.com --> output user ID claim 1234
liveId + me#live.com --> output user ID claim 1234
For the unique ID output claim type, you can pick from the available claim types or designate your own. ACS has an OData based management service which you can use to create these rules programmatically from your MVC application. Here's a code sample.
If you are using ACS, you can translate the information from each IdP (e.g. Gogle, Yahoo!, FB, etc) to a common handle using claims transformation on ACS. A common handle people use is the users e-mail. But if you want to accept many e-mails mapping to the same user, then you'd introduce your own unique id (as a claim) and map IdP supplied claims into it:
myemail#gmail.com (e-mail - Google) -> (UserId - YourApp) user_1234
myotheremail#yahoo.com (email - Yahoo!) -> (UserId - YourApp) user_1234
64746374613847349 (NameIdentifier - LiveId) -> (UserId - YourApp) user_1234
You can automate this through ACS API. You should also probably handle the first time user logs in into your site (e.g. asking user for an e-mail and sending a confirmation message that will trigger the mapping).
Presumably, you are using this information to retrieve data from a local database in your app, otherwise, you could just encode everything in claims and not worry about any equivalences. Claims are often a good place to encode common profile data. (e.g. Roles, etc)
Our company, Company A, may soon be partnering with Company B under some sort of licensing agreement. If it goes through, it will be necessary for users of Company B's web service to have access to Company A's web service. In other words, any user with an account for Company B's service should automatically have an account with Company A, but without having to create a new account...their's should be a shared account.
I'm not an expert in this matter (obviously) but I think this scenario would call for something along the lines of OpenID, but just between our two web sites. How would we go about sharing authentication is this way? I'm not familiar with the verbiage of the subject, which makes it difficult to google for guidance. Would this be a single-sign on?
Thanks.
You're really describing federation here, of which OpenId is one example (albeit one that's not suitable in this case). With federated identity Company A allows Company B to authenticate their users. This authentication process results in a token from Company B containing information (claims) about the user which is sent to Company A and used for authorisation.
Federation is not single sign-on, that tends to describe the situation where Company A runs lots of services and an authentication service as well - and logging into the authentication service allows a user to access all of the resources without having to re-authenticate.
Without knowing what the architectures involved are it's hard to recommend an approach. The standard way to transport claims is in a SAML token. In a Microsoft environment you can use the Windows Identity Framework to write web services which understand SAML, and ADFS "Geneva" to issue SAML tokens from an Active Directory. There are similar solutions for other identity stores, such as IBM's Higgins.
I don't think OpenID is really an answer here. It matters very much how users of B's web service currently authenticate to these web services. I assume that they use username/password pairs, and assume that you want them to continue doing so even for A's web services.
If so, the next question is how the password gets transmitted and validated. I assume that B currently uses "Basic Authentication" (you need to confirm this with B). If so, authentication is straight-forward in principle: In an A web service, also use basic auth, which causes users to send their passwords to A, IN PLAIN TEXT. Use https to encrypt the passwords on the wire.
Then, having a copy of the password, validate them with B, e.g. by having A's service sending a request to some dedicated service at B which just confirms the password as correct.
The downside of this setup is that users have to reveal their passwords to A; by means of the licensing agreement, you need to establish trust that A won't abuse these password (i.e. that they will not store them, and not use them to incarnate a user outside of the agreed processes).
You have two problems, I think.
Allow Company A machines to authenticate Company B users (and vice versa?)
Provide resources on Company A machines for Company B users.
Single sign on, or any authentication solution like OpenID, solves the first part (and may be sufficient for static content); you still will need to actually create accounts or otherwise allocate resources on Company A machines for these now authenticated users.
For example, StackOverflow uses OpenID to authenticate users. This means that StackOverflow can leave the part of figuring out who you are to other services, such as Google or Facebook etc. However, StackOverflow still needs to create a local account for you, to track your reputation, send you updates to your questions, and other things.
For just the authentication part, here are a couple of options:
If Company A already support OpenID, then Company B could just be an OpenID provider. You would still also want to add some code to Company A's website to ensure that a user logging in with OpenID is authorized, i.e., from Company B.
If Company A and B both use LDAP (e.g. Microsoft Active Directory) to handle authentication for internally, then you can probably add a forwarder to have Company A query Company B's LDAP servers to authenticate users (subject to appropriate firewall tunneling).
Or you can do it more statically, by having Company B provide a list of users, and having Company A pre-create accounts for all of those users ahead of time. This is the simplest but doesn't handle change of personnel from Company B very effectively, unless you set up an additional synchronization process. Here you would probably generate passwords (e.g., lastname+employeeID or random strings) for each account and have Company B distribute them to its users.