This is more of a philosophical/architecture question than "code" question.
Let's imagine that we have 2 applications (Service providers) with Single Sign-On. There is obviously data they have to share, mainly the information of the users (username, email, etc). This data is managed by the Identity Provider and "provided" to the service providers when the authentication is successful (the basics, I guess).
Let's also imagine that these 2 applications have their own database itself in which they match each user retrieved from the IDP but each database has their own info (columns) that only belong to their associated application (not to the other!). But (another but), there are some other fields that both have to access (besides username, email, etc). For example, the first application has a list of available companies and the second application needs that information when creating a new user to associate that user with an available company. How should that data be shared? Is that the best/correct way to create an API to provide this type of info between applications? I'm mostly talking about lists of things that are too big to be sent through assertions.
Thanks in advance!
The SAML way is to use NameID as the "primary key" to map a user in the IDP to a user in the application.
e.g. Email could be sent as the NameID for application 1 and UPN could be sent as the NameID for application 2. These would be in the assertions.
Getting info. between applications is not part of an IDP (other than using assertions) so this would have to be done via API.
Related
So, when management tells us our website needs to "support SSO through SAML 2.0", with no additional details, what are they thinking?
What will our customers expect?
Note - The is not an open website, where everyone can join. To log in you need to be a configured user in the system. The customer's admins need to create an account in our system for each user.
So we aren't going to let just anyone who has an account with an IdP in to our website. We'll have to have some mechanism for mapping a SAML identity to our users.
How would our customers expect that to work?
Based on hints in your question, I am going to presume that you will be acting as a service provider.
To be what I would call a "good" service provider, I would expect the following:
You sign your AuthnRequests.
You provide a metadata endpoint that is kept up to date with your SP metadata to include current public keys for encrypting attributes (if necessary) to be sent to you as well as validating your AuthnRequest signatures.
You support dynamic consumption of my identity provider's metadata endpoint to keep your side of the connection up to date, especially with concern to my signing certificate.
You expose management of my identity provider configuration inside of your service provider mechanism to my IdP administrators through a web or API interface.
You either support a mechanism to automatically manage my users (like via SCIM or Graph or something else), or you support Just-In-Time provisioning based on an incoming assertion.
You allow me to decide my SAML Name ID format, and that format is per-tenant. As an example, I may want to use email address as the identifier, while another IdP may want to use sAMAccountName. e.g., john.doe#domain.com vs. johndoe.
You support Service-Provider-Initiated SSO. That means that the user shows up to partner1.yourdomain.com and get redirected for authentication to that partner's IdP, and that going to the location partner2.yourdomain.com would redirect to a different IdP.
As a service provider, you should make using your service easy and secure. By shifting to SAML, it allows you to get out of the business of password and user management because you get to put that back on the identity provider. It allows your users to not have to type in a password (or more, if you're doing MFA) to use your service, removing friction caused by security. It allows you to put the onus of authenticating the user back on the organization that owns the identity.
Your customers would expect that if they have an application that uses the SAML 2.0 client-side stack then when the application sends an AuthnRequest, they will see a login page on your site and once authenticated, the application will receive a set of assertions (claims) from your IDP via an AuthnResponse.
One of these assertions is NameID. This is the "primary key" between their system and yours. Normally this is UPN or email.
This mapping is outside of the SAML spec. There needs to be some kind of "on-boarding" for the customers.
Currently my organization uses a number of web apps/mobile apps/APIs, some of which authenticate against an in-house IdP and others which use a third-party proprietary system (over which we have no control).
We have been asked to implement SSO for these web applications and as a result I have been reading up on OpenID Connect. I believe this would be a better solution than SAML given that (a) end-users are not always enterprise users, and (b) SAML not designed for mobile applications.
I believe I understand the flow reasonably well but have one sticking point. To allow users to authenticate using an external IdP, we would need to map the user back to our internal id. For example, user authenticates using OIDC/Google, resulting in us receiving the user's unique Google idenitifer (and email etc if we queried further), but this is not useful to us until we can map the Google identifier back to our internal customer id.
Is this mapping out of scope for OIDC? If so, is there a best-practice method for doing this? I'm sure we are not alone in this requirement...
Thanks,
John
Is this mapping out of scope for OIDC?
Short answer, yes.! If your backend require a comparison/validation with internal identity details, then it has to be done out-of-scope of OpenID Connect(OIDC) protocol. OIDC simply define the process of obtaining tokens (ID and access token), which are required for authentication and authorization.
is there a best-practice method for doing this?
One option is to use out of band directory synchronization. For example, Google provider Google Cloud Directory Sync (GCDS), which allows you to synchronize identity details to LDAP or MS Active directory. Other alternative is to use SCIM protocol to communicate and provision users dynamically. For example Google provide that support as well.
Alternatively, you can use just-in-time provision at the time you receive tokens. This support will depend on your identity provider implementation. For example, WSO2 identity server support both JIT provisioning as well as SCIM.
I'm working on setting up a service provider that supports SAML. I've added two identity providers - one custom one that I built from SimpleSAMLphp and then ssocircle. So I log in to the selected identity provider, and then it returns to my service provider and I inspect the attributes of the SAML Auth object. The identity provider I built returns whatever I want it to (obviously). The ssocircle one only returns e-mail, first, and last names.
So now to map this to the user of the service provider, I have to use some value the identity provider provides. So this led me to wonder how it should be done. Since ssocircle only gives me e-mail as a useful value, do I just use the e-mail to map to the SP user?
Let's pretend for a second that ssocircle doesn't validate e-mail addresses. So now if I create a second account at ssocircle with the same e-mail, I can log in as my coworker who I know has admin privileges.
So my question is, do I handle this? Or is the onus on the admin who set up the identity provider and say "well you shouldn't have used an identity provider that doesn't validate e-mail addresses!" or something of that nature? Or should I only allow identity providers that pass a certain value, like userid or 0.9.2342.19200300.100.1.1? Is there something that identity providers commonly use?
Well, you said it, two different identity providers. They both should be passing not only the email but different entity ids and certificates.
In multi-tenant applications that would mean two different applications, but if you plan to allow multiple IDPs to point to a single app you will need to ensure that same email but different entityID create two different users and or throw an error after the first was created that the second cannot be provision nor access.
Interesting question. These days people think always of auto federation of users by some attribute. In early SAML federation days federating two unrelated users was a manual step in which a user logs in at the IDP and logs in to the SP providing both sets of credentials and then manually federated these two user accounts. The process guarantees that only the user who has access to the accounts at the IDP and SP controls the linkage between the two. It also allows anonymous naming identifiers (SAML persistent NameIDFormat) which protects privacy because even the IDP does not know the user name at the SP and vice versa.
Unfortunately the process was to complicated for users and with the success of OpenID the aspect was getting less and less important.
To answer your question: What you describe happens in the real world -see Office 365 authentication bypass
You need to check that the IDP is authoritative to send a specific attribute and attribute scope in case of two IDPs.
In case of one IDP the attribute must be verified (SSOCircle verifies email address) and it should better be unique (For example SSOCircle userId) to avoid that two users with the same attribute are mapped to a single user at the SP.
If the userid's are not the same (e.g. you use a simple user ID at the IDP and email address format at the SP) you can still add a correlation attribute at the SP (e.g. an attribute named ssocircle-userid) and use that to link the user accounts.
I'm using SAML for login into my app, I would like to include the user groups in attributes in the login response assertion. I'm wondering if the login request should specify that the attribute is required, or if this is a configuration that needs to be done on the IDP in general, or in the IDP specifically for my service provider.
I've created Identify Provider in OpenAM and have my own APP Service Provider configured in OpenAM as remote SP as well, I've also created a user in OpenAM and assigned it to a group, however, I'm not seeing the group in the response assertion, even when I tried to map the value in OpenAM manually, the memberOf attribute always returned empty.
Any information will be highly appreciated.
Shay
The best answer I have for you, is that there is no good way to share group membership information in SAML2 assertions OOTB.
I would suggest to implement a custom attribute mapper and implement the retrieval of group membership data there, but you will find that the DataStoreProvider interface does not expose group membership related operations, so you would need to directly use the AMIdentity/AMIdentityRepository API in your plugin.
When it comes to group memberships you have a couple of choices:
return the names of the groups
return the DN of the groups
return the Universal ID of the groups (universal IDs are OpenAM's internal unique IDs that is stored in DN format, but it is not the same as the groups DN in the directory server)
The first option would be my personal recommendation as that fits into OpenAM's abstract user data store concept.
I am reading about SAML2.0 based federation as it is supposed to apply for SSO in the current setting:
In application A a user has credentials email/password1
In application B, the same user has credentials username/password2
If the user logs in at A, he/she should also be logged in at B
SAML v2.0 seems to be a good choice in this situation:
central identity provider (IdP), maybe A or B or a third party C.
A and B would be service providers (SP)
if user tries to access A, A would request SAML assertions from the IdP containing email
if user tries to access B, B would request SAML assertions from the IdP containing username
But if the user is authenticated in A, how should he/she be logged in B (for which username)?
Documents about SAML (e.g. here: https://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf) pretend that SAML allows SSO without requiring to synchronize or migrate identities between all players.
However, I don't see, how all this should work without maintaining and merging all credentials of the same subject in the central IdP which in fact is a kind of synchronization.
If you have the impression that I am quite confused about SAML v2.0 capibilities, you are right ;-)
As a service provider, SAML doesn't allow you to do away with a user store usually. This is because it's a method by which you externalize authentication only. Most service providers have a 1-to-1 relationship of users in their store, to users at their identity providers. However, it may not need to be this way, as you can do a one-to-many federation as well. I'll expand shortly.
In the one-to-one, you will generally use either a "just in time" provisioning method, or an out of band user synchronization method. The just in time is usually done via attributes provided in the assertion, and is done by the SP when it realizes that the user that has been presented in the assertion doesn't exist the application's user store. The out of band method is some other process, a directory synchronization, etc. A user gets add to the IdP's store, and some process adds that user to the SP store, via flat file, XML, etc.
Having said that, depending on the type of service provider, you could do a one-to-many, and count solely on the attributes provided to support the needs of the application. Let's say you run a printing operation. You could agree on having the IdP send a cost center along with other attributes for the user (name, number, email, etc.). Then all the data is stored just on that print job, with the Cost Center sent back during billing. I will say, I've only seen a couple of instances of one-to-many federations in my career.
I don't think your example is quite right - meaning you didn't ask it quite right, but then again, you're not familiar enough, maybe.
Let's presume the following:
Service Provider X needs username
Service Provider Y needs email
Identity Provider A can provide all of these from their user store
The user shows up at SPX. SPX says "based on the url you went to (idpa.serviceproviderx.com), I know you need to be sent over to IdPA." and redirects the user to IdPA. IdPA authenticates the user, looks at its "attribute contract" to determine that it's supposed to send username to SPX, and redirects the user with that attribute as its "subject" in the assertion. SPX consumes that assertion, and can map the user back to where they are supposed to go.
Now, the user is browsing through their portal, and clicks a link that starts an SSO to SPY. The user is already authenticated to IdPA, so IdPA checks it's contract and sees it's supposed to use email with SPY. It creates an assertion for SPY with email as the subject, and redirects the user to SPY for consumption of the assertion and connection to the application.
Now, in both those instances, the IdP has to determine what to send to complete the contract with the SP - and it always will. This is based on a "contract" - some form of agreement between the IdP and SP that has to be supported by administrators of both systems.
Ok, I think the main missunderstanding here is how authentication works in SAML. I SAML the IDP authenticates the user. This means, you have no crederial store at the SP.
SSO in SAML happends at the IDP. If the user has already signed in once at the IDP the user is just sent back to the SP without authenticating.