Say you have an IdP that can act as a SCIM server (WSO2 is one -- I would be interested to know if there are others), but SCIM is not currently enabled and it is up and running for a while with user Fred. Fred has a user ID of 31415. Now we decide to enable SCIM on the IdP and a client makes a SCIM query for the users. Will Fred's ID (prominent in the JSON response) be 31415, or would enabling SCIM have caused the IdP to generate additional/new SCIM IDs for all the users? I know for normal, non-SCIM operations, Fred would still be associated with 31415, but maybe for SCIM operations there would be a new ID.
Either approach would be acceptable. I don't know the specifics of any SCIM servers, libraries, etc on how they'd treat it. For simplicity's sake, if possible I'd recommend representing the existing internal ID value of 31415 and using that for the SCIM ID value as well.
Related
SCIM makes an optional 'externalId' attribute available for clients which have a different value for a user's ID than what the SCIM server authoritatively associates with the same user. What if we have a scenario where there are 3+ domains, one containing an IdP which can act as a SCIM server (aka., service provider), the others containing SCIM clients which make use of the IdP. A given user could have accounts in all the domains and each domain may have assigned a different ID to that user. It seems like the 'externalId' attribute could help with one of the client domains, but not any others. Would we have to define SCIM extension attributes to handle the other client domains?
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.
In any B2B Web application users has to be provisioned against an entity. For example, Acme company users shall be provisioned for Acme entity only.
I am trying to test my user provisioning APIs with OneLogin "SCIM Provisioner with SAML" connector. But I am not sure how to identify the user's organization entity.
Is there any way to identify user's organization entity other than bearer token?
The most 'user-friendly' (integration admin friendly?) way is to use the bearer token. This way the SCIM URLs that a client talks to will always be the same. Additionally, you're enforcing which entity is being affected.
The other (less common) way I've seen an application implement this is by using a unique URL per entity. i.e. https:// entity_name .ServiceProvider.com/SCIMUrl/
But even if you go with this unique URL mechanism, you're going to have to make sure the bearer token was created for that specific tenant (otherwise I can use my token to access another tenant's data)
So you might as well implement it the first way, in my opinion.
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.
What I know so far is, to make any application SSO enabled, there must be an Identity provider taking part in the SSO game. So there is direct dependency on IDP as the SP need to "know" who the IDP is. Can SP have a common saml communication mechanism which can work with any IDP that my customer is using ? Or I need to build different saml communicator based on the customer supported IDP ?
Reason: One of our company customer is using Okta for its employees and want us to make our application Okta enabled so that its employees need not to remember credentials on our site anymore. That's fine. Now, if any other customer comes with some other IDP (PingOne for example), do we need to work again to make it that xyz IDP enabled ? or our existing implementation will work same way by just adding that IDPs url ? Let me know if I am missing any big picture or key concept here.
P.S. Our application is on .NET platform.
Unfortunately you will need to create a new association if a user want to use a new IDP.
There is a good reason for this. You need to be say that you trust the IDP. The IDP is the one that vouches that the user is who they say they are. So you have to ensure that you trust it to authenticate users for you system.
What you could do is to allow for the customer to define its the IDP to be used, provided that the IDP is only allowed to authenticate that customers users.
If you want to do this I would recommend using some third party software.