User Authentication in SAML and OIDC federation
Federation was designed to enable trustworthy access across separately managed domains of users and information. Described simply, in federation one domain (or organization) maintains a population of users and the methods available for those users to authenticate. The second, separate domain maintains the application or information the users want to access, and, accepts and validates the minted access pass issued by the first domain. By not having to manage the users’ account lifecycle and the user authentication process, this process enables the second domain to simplify their management tasks and lower their management costs. All the second domain requires to grant access is the access pass, minted in a standard form (SAML or OIDC) and digitally signed with a private key that is bound to the originating organization. This arms-length scenario seems simple enough, but things get more complicated when organizations want to truly embrace digital transformation. The digital transformation journey drives organizations to open access to all possible relevant information for all constituents from any location. A great target to aim for, but security practitioners and, more broadly, anyone that pays attention to news broadcasts knows pursuing that goal potentially exposes an organization to potentially painful, public, and highly expensive problems when sensitive information falls into the wrong hands. Risk of exposure increases when just a username and password unlock access to all information across a federated partnership.
For a long time, CA SSO has provided access control to information in some of the largest most security-sensitive organizations in the world. The product continues to evolve to support use cases these organizations are implementing in the digital transformation journey. A quiet, useful capability not in the marquee limelight but highly useful in arms-length federation transactions that are part of the digital transformation is Dynamic Authentication. CA SSO offers support for this capability in both SAML and OIDC use cases. In a nutshell, the business value intent behind Dynamic Authentication is to lower the cost of federation management and increase the flexibility to support different forms of user authentication to enable access to varying levels of sensitive information across the federation bridge. Quite a trick if both of those values can be accomplished in parallel.
Here is a high-level description of how it works in one use case.
For the deeper description search for “Dynamic Authentication” in the online technical guides (use the quotation marks when you execute your search).
An administrator at an organization using CA SSO as a SAML Identity Provider (IdP) will create an authentication context template in CA SSO. This is just a fancy name for a template that maps user authentication strength levels to the location where a user will authenticate to achieve those strength levels. Then, the administrator at the IdP configures a federation partnership with a Service Provider in CA SSO and, for “Authentication mode”, they select “Dynamic” and then they select the specific “Authentication Context Template” they want to apply. How does this help lower administrative overhead? Well, rather than setting up multiple configurations to accommodate different applications at the Service Provider that need different levels of user authentication strength, with just a single federation configuration using Dynamic Authentication your users (remember you are the IdP in this use case) will be prompted to authenticate with a dynamically determined authentication method based on the real time signal provided by the Service Provider during the transaction. It is likely, over time, that any single Service Provider you have a federated partnership with will want to expose different information requiring different levels of user identity proof (i.e. different levels of user authentication) to your users. So…if, as an IdP you can accommodate that with a single configuration…that saves time and increases the level of security of your federated interaction. Trick Accomplished!
While this blog focused on a single example, I encourage you to dust off the on-line CA SSO technical guide and see how this works when you use CA SSO in a SAML Service Provider capacity or implementing OIDC.