Our customer is using Okta and is asking us to SAML-enable our app so they can access it using idnetities in Okta.
We plan to use OpenSAML to do it. So far so good.
But usually, our app has access to identities (list of users, groups/members) coming from an on-prem LDAP or AD, for example. We normally use those identities to configure authorizations in our app (give permissions to certain users to access certain ressources). Using SAML only, I don't see how to access the whole list of users/groups. And from what I understand, it's not the goal of SAML to provide it.
How is this situation typically solved? Should we try to sync the identities between Okta and our app? Is it what is called provisioning? There is Okta API, SCIM, JIT, ... Or maybe we should take a totally different approach?
Thank you!
The typical way to handle authorization in SAML is to use a SAML assertion to determine the authorization that a user should have. Which assertion is used and how it is will depend on your authorization model.
Note that using assertions will push the responsibility for determining authorization onto the administrator of the SAML Identity Provider, it will be up to them to decide who has access to what.
The ideal situation for supporting "enterprise federation" is to support SSO and Provisioning. SAML or OIDC for SSO and SCIM for provisioning.
If your software doesn't depend on an up-to-date list of users, supporting just SAML with "JIT" might be sufficient. SAML with "JIT" or "Just In Time" provisioning just means that your SAML Service Provider implementation would add users that it hasn't seen before.
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.
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.
First of all I do not have any experience with SAML (version 2).
I was asked to investigate how we can make an existing site, which has a normal login page with a username and password page, ready for SSO with SAML.
There are some tools around which we can use in order to do this.
So I think it is not so difficult to implement the SSO part.
But however it is not clear to me how the authorization is managed.
The system (web site) is using authorization rights in order to determine if the user is able do access certain parts and if he does, the right type he has (view, create or edit).
These rights are assigned to each user by an administrator in the system itself.
When a user logs in the system by specifying his credentials (without SAML/SSO) his rights are also retrieved.
How is this done when a person logs into the site by using SSO?
Is there a mapping of the userId which is know by the IdP (Identity Provider) to the userId which is know by our system?
And is this send in the SAML response from the IdP?
Or is this done in another way?
Thanks in advance
SAML is mainly a authentication protocol but there are still many ways to solve this. SAML supports sending authorization infromation in AuthzDecisionStatement in the assertion.
Another alternative is to extend SAML using XACML which is a big framework for transferring Authz information.
However the support for these are limited in many SAML providers.
The simpler solution and probably the best in your case, if it is just one access right per user, is to send it as an attribute in the SAML assertion. This can usualy be mapped against for user properties.
My understanding of the SAML (v2) protocol is that Service Providers should be interacting directly with Identity Providers to exchange authorisation request and assertion messages.
I can think of a number of reasons why this would be a bad idea (undermines message signing, gives intermediate IdP access to info from other IdP), but are there any scenarios supported by SAML that would allows the following arrangement?
SP <------> MainIdP <------> ThirdPartyIdP
So (hypothetically) assuming that MainIdP has some clever way of determining that the SP user needs to authenticate against ThirdPartyIdP, it would delegate to the ThirdPartyIdP and then receive the response, process it and reply to the SP. Does SAML allow this? (I am asking because a software supplier has suggested this approach and I believe it isn't supported, as well as being fundamentally insecure.)
The "correct" approach as I understand it is for the SP to be configured to know about both IdPs independently, and either present the user with a list to pick from, or delegate to a Discovery Service which can ask the user, or infer by some other means, which IdP to use. Is this right?
Thanks.
Most federation identity providers for SAML have the concept of a "Home Realm Discovery" screen.
The SP is "bound" to the MainIdP but the MainIdP presents a screen which shows all the other IDP's that it is federated with. From that list, you pick the ThirdPartyIdP.