We have an application which supports a single Identity Provider. However we have multiple customers on it and each of these customers wants to point to their own Identity Providers. It would be a significant amount of rework to allow our application to support many providers. We are looking for a solution (open source or commercial) where we can point our application at a single Identity Provider and (presumably based on email address domain) that Identity Provider can route the requests out to a specific clients Identity Provider. Do such solutions exist?
Yes, it's called Home Realm Discovery.
You federate all these other IDP with your IDP.
When the user logs in they get a choice of which IDP to use to log onto.
Most IDP have rules that allow the IDP to be selected seamlessly.
Related
We have in my organization an existing ASP.NET web application built in a SAAS model that our customers (users from different organizations) login through username/password authentication method. Users' credentials are hashed and stored in our database. We are currently working on adding a SSO feature to our application that would allow end-users from certain organizations to login with SSO using their own Identity Provider (Azure AD, Google, Okta, etc.) to perform the user authentication. We are using the OpenId Connect protocol to establish the SSO connection with IdP, and more specifically the Open Web Interface for .NET (OWIN) middleware. We have implemented the following:
Our SAAS application offers customers the ability to opt for SSO authentication through a setting. End-users from these organizations will be authenticating to our application via SSO AND using their own IdP
Our application supports SSO connection from different IdPs (Azure AD, Google, Okta, etc.)
Our application stores SSO connection settings for each customer that opt for SSO authentication (Client Id, Authority, Secret, etc.). All these settings are configurable in our application, they're available upon registration of the application on IdP side.
My question is about the app registration. I know that in order for our application to communicate with IdP and initiate SSO authentication it needs to be registered on related IdP, so that it can create a trust relationship. I am wondering which party should be responsible of the app registration:
My organization owner of the SAAS application? or
Our customers willing to use SSO authentication method?
With option 1, my organization will have to have an "account" on each of the IdPs our customers use for authentication (I feel this is not ideal for us), register our application and have a mechanism to invite our customers IdP to connect to the registered app.
I feel like option 2 would be the best approach for us as we won't have to deal with app registration, as customers will be responsible of registering the application on their own IdP. From my organization end we will just need to deal with SSO connection settings (Client Id, and other...) which will be provided to us by our customers upon app registration. I wanted to check if this is a common situation that some have already experienced, and what would be the best/recommended approach to go with. Thanks.
I am expecting app registration to be performed on customers side.
I would usually recommend that your internal services and APIs only need to trust tokens from one Identity Provider, and in your case you have one openid connect provider inhouse. That then supports your users to authenticate to and optionally authenticate using an external provider, like how the image below tries to show:
In my experience, having your applications trust and handle tokens from multiple sources will be a pain, as many of the external tokens might look slightly different.
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.
I’ve done a few OpenID integrations, so I understand the problem I’m about to describe is something OpenID and OAuth can solve, but I’m new to SAML and trying to wrap my head around one particular use case:
So, say user visits Site1, which asks the user to confirm which one of the other sites he or she belongs to (Site2, Site3 etc.)
Site1 cannot authenticate user and relies on Site2 or Site3 to do authentication, so it presents user a list of sites to authenticate against.
User chooses either Site2 or Site3, performs authentication there and is redirected back to Site1. Site1 acknowledges the user and it now knows where the user is from.
Question: Is this a valid problem for SAML to solve?
There are two problems in your question:
Service provider (Site1) needs to redirect the user to the identity provider (Site2, Site3, ...) that "owns" the user identity (can authenticate them)
Authentication at the identity provider and propagation of this fact back to the service provider
SAML can solve both of these but read on for caveats:
One of the profiles in SAML is an Identity Provider Discovery profile. Its definition from the spec (section 4.3):
...a profile by which a service provider can
discover which identity providers a principal is using with the Web
Browser SSO profile. In deployments having more than one identity
provider, service providers need a means to discover which identity
provider(s) a principal uses. The discovery profile relies on a cookie
that is written in a domain that is common between identity providers
and service providers in a deployment. The domain that the deployment
predetermines is known as the common domain in this profile, and the
cookie containing the list of identity providers is known as the
common domain cookie.
As you can see, this profile relies on a common domain cookie that is issued by a discovery service hosted on a common (shared) domain:
When a service provider needs to discover which identity providers a
principal uses, it invokes an exchange designed to present the common
domain cookie to the service provider after it is read by an HTTP
server in the common domain.
The common domain (and associated cookie) requirements were an early take and some developers didn't think it was an elegant approach that met everyone's needs. This lead to the profile being revised and later issued as a separate specification called Identity Provider Discovery Service Protocol and Profile. From this spec:
This specification defines a browser-based protocol by which a
centralized discovery service can provide a requesting service
provider with the unique identifier of an identity provider that can
authenticate a principal. The profile for discovery defined in section
4.3 of [SAML2Prof] is similar, but has different deployment properties, such as the requirement for a shared domain. Instead, this
profile relies on a normative, redirect-based wire protocol that
allows for independent implementation and deployment of the service
provider and discovery service components, a model that has proven
useful in some large-scale deployments in which managing common domain
membership may be impractical
The mention of large-scale deployments is important. The first attempt (cookie-based profile) was simple but messy; the improved spec does everything the "SAML way"...and greatly increases the complexity of the implementation. It's only worth it if your collection of identity providers is sizable, like all universities in your country for example.
There are many non-SAML options for solving the identity provider discovery problem. The simplest option is "ask the user" by employing a UX-friendly technique for the user to select their identity provider. This blog does a good job of summarizing these options. For a real-world, complex solution to this problem take a look at Swiss universities' implementation.
This is a common scenario where SAML is a good fit. Take a look at SAML Technical Overview for more details.
Note: oAuth does not authenticate the user, it authenticates the client app. OpenID Connect is based on oAuth and it can authenticate the user via the id token. The id token and the associated exchange was heavily influenced by SAML
IDP's handle this via Home Realm Discovery.
If an IDP is configured with Sites 1, 2 and 3 then when the application redirects to the IDP, there will be an HRD screen asking the user to pick one of the three.
The user selects one, authenticates and is redirected through the IDP back to the application.
It's not a protocol feature - more of an IDP feature - since it does this irrespective of the protocol.
A customer is currently trying to decide if they want a SAML 2.0-based SSO implementation for their application. However, their users have many different identity providers. I have build some SAML-implementations, but they were all for one identity provider only and I don't have any hands-on experience with one application using many different identity providers.
Question: can you generally build one configurable SAML-client for multiple identity providers or do you have to build multiple distinct clients in order to service them all?
A single Service Provider (SP) can use as many Identity Providers (IdP) as it wants. The only thing the SP needs to know is which IdP to use for a particular user. It does that in one of two ways. Either it displays a list of IdPs it knows about and the user selects one, or the user arrives at the SP on a 'WAYF-less' URL. WAYF means Where Are You From but is largely superceded by the SAML discovery process. Providing the entityID of the IdP to the SP bypasses the WAYF, hence WAYF-less URL.
e.g. you could have a URL scheme along the lines of:
https://yourapp.com/login?idp=https://someidp.com/shibboleth
https://someidp.com/shibboleth is the entityID of the IdP. Your SP looks up that entityID in its metadata store to find the SSO URL of the IdP and sends the user to their correct IdP for login.
Once your SP redirects the user to their IdP, SAML flow is normal after that. So the only thing the SP needs to do is work out where that SSO URL is. All the IdPs will return the same SAMLResponse format but with their own attributes etc of course.
I am going to talk in terms of SAML but I'm not fussed about the protocols.
There will be a Federation Provider (FP) that trusts a number of external and 1 internal Identity Providers (IdP). The applications (SP) will in turn trust the FP. The SPs are a mixture of Java and .Net. The external IdPs won't know the permissions and claims to add to their security tokens for use by the SPs but the local IdP will. I need to associate the appropriate roles, permissions and groups to the identity so an SP can grant or deny access appropriately.
I can see 2 options:
The FP maps the external identities to local ones and does claims augmentation by querying the local IdP and enhancing the security token with the appropriate claims before passing to the SP.
The SP queries the local IdP and extracts the permissions that way.
What are the common patterns in this area?
Bonus points for suggesting products that support either of these scenarios (note: not a product recommendation which would be subjective, just a statement of capability)
Update: I have been impressed with the capabilities offered by Shibboleth SP, particularly the way it operates at the web server level freeing the application from the responsibility for handling SAML.
https://shibboleth.net/products/service-provider.html
We have built something similar to this, although our solution may not meet yours. Our model is a hub and spoke federation model where our hub maintains information about all users who have authenticated at least once in the federation. We provision the users on demand (ie: upon authentication) and allow augmentation of the users' data in the hub by administrators. We hide the very heterogeneous collection of authentication systems (SAML, CAS, LDAP, OpenID Connect) from the SPs that use the hub and normalize the claims that are passed to the SPs. In general, on the IDP side of the hub, the hub acts as a service provider; on the SP side of the hub, the hub acts as an identity provider. We've found that isolating the variability of the IDPs from the SPs is an effective abstraction for our SPs.
The architecture you describe is a common design pattern for a product (set of applications) hosted on the internet, where your users/partners have the option to provide an IdP or utilize your IdP for authentication. Many regulated industries require that Authorization be performed by the party providing the web applications and services. Since you will be doing authorization and adding attributes, you will need to manage all the user identities and have information provisioned for those users into your local database. Upon receipt of the authentication assertion, then it will be augmented with authorization information from your local database.
There are many on-premise Federation Solutions on the market today that perform the function you have described. I am going to focus on a SAML solution here, although there are other options for federation protocol. A couple of terms so the answer is more clear. The Identity Provider(s) will be the components that issue SAML assertions and only perform authentication, the Service Provider (SP) will be the component in your network to request/receive SAML assertions as well as augment the assertion with authorization data from your local database, and web applications to receive identity tokens, which are your applications.
Within the context of your network you will have a federation server that acts as the SP using the SAML protocol to all the desired IdPs. This component is essentially a federation hub. All of your web applications will communicate with this federation hub. An IdP Discovery service will be needed to determine where to route the SAML Request, which can be implemented within the federation hub, or in each application. My preference is to have the IdP Discovery as part of the federation hub. There are a couple of options for discovery such as using URLs or having a selection interface displayed to the user which is driven by the type of requirements and use case (workforce, business partner, customer). When your web application invokes the federation hub and associated IdP Discovery, then the SAML request will be sent to the appropriate IdP. Upon receipt of the SAML response, the assertion will be validated and subject retrieved. This is where some options come into play based on the vendor and business requirements you have for the solution. Products that act in the SP role as a federation hub that receive SAML assertions generally will have some type of plug-in interface or configuration that allows you to query for attributes from your local user database (or a directory service). Once all the data is combined, then a last mile integration occurs, either using SAML protocol, vendor protocol, or web service to the federation hub to get all the identity information. Since you have requested product that meets this use case, I have worked extensively with PingFederate by Ping Identity that will solve what you are looking to do.