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.
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.
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.
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.
Say I'm a small application (www.example.com) and I'm integrating with a much larger enterprise (www.acme.com).
In this scenario I am the service provider and they are the Identity provider.Their request is that I integrate into their auth ecosystem using SSO (specifically SAML 2.0).
For the standard IdP-initiated flow, users will sign in on their end and they will POST an XML assertion to my application, which will then verify the user and sign them in to my application (i.e. set a browser session).
The enterprise uses PingFederate as their identity server, and they are curious what implementation my application uses. At this time I have none.
If my application is a single monolith (e.g. a small Ruby on Rails app), do I even need a federated server? Ultimately they are just looking for a place to POST SAML data to, so I can set up an endpoint and go from there right?
What are some general benefits of a federated server? Why wouldn't every service provider application (small and large) just set up an endpoint to ingest SAML data and call it a day?
Thanks!
You don't necessarily need a Federation server. However, if you decide in the future to divide/expand your application into micro-services or integrate your service with other 3rd Parties, a server will allow you to scale without disrupting your current customers (great CX) and not have to manage separate security endpoints.
I think we should move this to software engineering
How do users authenticate with your service? Having a federated identity guarantees that the whole user management process it's someone else's problem. They're looking for a way to integrate your service into their authentication system, so you need to set up an endpoint not only to consume but to be able to send SAML request to their identity server as well.
I use my Google Account credentials to access almost all my social networking sites (including Stack Exchange), that means among other things that all sites know me as the same entity plus I just have to remember the one password.
Don't know about SAML but almost everybody is using OpenId or OAuth.
I'm researching about CA Single Sign-On software (formerly CA SiteMinder®) and came across with two new definitions to me:
Web Access Management (WAM)
Identity Management (IdM)
On Wikipedia state these definitions:
IdM: "In computing, identity management (IdM) describes the management of individual principals, their authentication, authorization, and privileges within or across system and enterprise boundaries with the goal of increasing security and productivity while decreasing cost, downtime and repetitive tasks."
WAM: "Web access management is a form of identity management that controls access to web resources, providing authentication management, policy-based authorizations, audit and reporting services (optional) and single sign-on convenience".
Despite of these two definitions seem to be clear, the more I read about them the more confused I am because I don't catch what tasks are exclusively of WAM and what of IdM. Where are boundaries? In what moment do they interact? Who is on charge of SSO? Both definitions talk about authorization and authentication and that confuses me.
I'm asking this because according to Liferay Wiki "Computer Associate’s (CA) SiteMinder is a centralized web access management system that enables user authentication and single sign-on, policy-based authorization, identity federation, and auditing of access to Web applications and portals."
If you reach "Architectural Use Cases: Simple Deployment" section (Implementation Guide -> Architectural Considerations) you'll see a diagram. If CA SiteMinder is a WAM: why does it do Authorization and Authentication? Do not are those tasks belong to an IdM? Is CA SSO also an Identity Access Manager? Then why does exist a product called CA Identity Manager?
Thanks.
PS: Feel free to correct any grammar or semantic mistake, I'm not English-Speaking ;-)
Identity Management (IDM) is concerned with the identity. Think of it as your digital wallet, as it contains all the information about you. This information can be used by other applications and is used by the Access Manager to control security. IDM does not manage security directly.
Access Manager (AM) can be some type of proxy system. For example, I currently use Novell, which leverages a reverse-proxy configuration. Access Manager is responsible for security and controls access to one or more resources for that authenticated user. In addition, it can provide SSL, Secure VPN, single sign-on services, SAML, and Federated support.
You normally need both component to build a complete Access Management System for an organization.