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.
Related
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.
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.
Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?
I am aware that this is not the usual way for SAML to work.
The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.
Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.
The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.
Question 1: Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?
Answer:
Definitely No, from the cybersecurity perspective.
Question 2: I am aware that this is not the usual way for SAML to work.
Answer:
Yes. You are correct.
(I) The SAML specification defines three roles: a user, an identity provider (IdP), and a service provider (SP). In the primary use case addressed by SAML, a user requests to access a service or log in to a web application from a service provider. The service provider requests and obtains an authentication assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision for the user, that is, it can decide whether to allow the user to access the service or log in to a web application.
(II) Before delivering the subject-based assertion to the SP, the IdP may request some information from the user (such as a user name and password) in order to authenticate the user. SAML specifies the content of the assertion that is passed from the IdP to the SP.
(II.a) In SAML, one identity provider may provide SAML assertions to many SPs.
(II.b) Similarly, one SP may rely on and trust assertions from many IdPs. This will be the SAML scenario of your web application if your product manager decided to request all 4 different clients of your web application to develop their own SAML IdP. For example, some social websites allow their users to log in to their web account through identity authentication provided by the third-party IdPs such as Google, Facebook, LinkedIn via OAuth 2 protocol or OpenID Connect protocol/OAuth 2 (instead of SAML).
Question 3: The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.
Answer:
If 4 different clients for your web application are supposed to enable a central password via SAML, they can implement their own SAML IdP in completely different technologies or programming language such as Java, PHP, or Scala.
(I) For example,
We developed our former version of Zero-Password Authentication and Authorization System in Java and leveraged Java-based Shibboleth IdP to provide SAML SSO for enterprise applications.
We developed our current version of Zero-Password Authentication and Authorization System with scalability and high availability in Scala to provide SAML SSO natively for enterprise applications without Shibboleth IdP.
(II) No matter which technology or programming language are used by 4 different clients of your web application to implement their own SAML IdP, their SAML IdP only needs to authenticate their users using a central password data store/repository (such as OpenLDAP or MySQL) locally and then deliver the user info using SAML assertion/SAML response to your web application/SAML service provider. Your web application/SAML service provider just needs to map the user info carried by SAML assertion to a local user info of your web application.
Question 4: Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.
Answer:
If the user identity authentication needs to take place centrally in your web application instead of in the SAML IdP, then 4 different clients do NOT need to implement their own SAML IdP from the cybersecurity perspective.
Instead you just need to create and assign different sub-domain to all 4 different clients, that is, all 4 different clients of your web application access different sub-domain, such as client-org1.your-web-app.com, client-org2.your-web-app.com, client-org3.your-web-app.com, client-org4.your-web-app.com.
Note that different sub-domain of your web application displays the same login webpage. Example #1: client-org1.box.com, client-org2.box.com if your clients also subscribe Box account, or Example #2: client-org1.my.salesforce.com, client-org2.my.salesforce.com if your clients also subscribe Salesforce account.
Question 5: The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.
Answer:
Different sub-domain of your web application displays the same login webpage.
4 different clients of your web application access different sub-domain of your web application, users of 4 different clients submit their login and password to your web application (through different sub-domain URL), just like without SSO, and the data store/repository of your web application is supposed to verify the access data (i.e., login username/password) centrally. Then 4 different clients of your web application do NOT need any SAML IdP.
I am looking to do IdP Discovery and i need to do this with Pingfederate Software. End Goal here is customers will request access to a resource. Then get redirected to an IdP where they see a logon form ... input their email address and then depending on their email domain they get redirected to another IdP where authentication will take place. SAML Assertion will get posted back and the customer can then access the application.
I know pingfederate has persistent cookie etc but i dont think this will work well. Has anyone tried IdP Discovery in Pingfederate?
The PingFederate Standard IdP Discovery is a cookie based mechanism that identifies the IdP, or matching of entityID to IdP. We have used the OOTB PingFederate capability and found it does work well for certain use cases and business requirements for user experience. This blog describes alternative approaches that are popular within industry to accomplish IdP Discovery. We have found that most service providers tend to use one of the forms of IdP Discovery described in the blog. The real driver for the implementation approach is business requirements for user experience. For PingFederate, if you choose not to use the out of the box cookie mechanism, then you will need to implement one of the other design patterns. I do know that there are Ping System Integration partners that have expertise and implementations of each of the design patterns described.
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.