More and more customers with federated SAML 2.0 approaches are approaching us and asking why, in addition to SAML 2.0 and an infrastructure for pure access control, an identity management solution is needed for the central assignment of rights? Many people think that all the necessary role information can simply be sent via an attribute in the SAML ticket. However, this so-called “just-in-time provisioning” of identities and their rights poses a number of hurdles that can be solved using a central identity manager.
But first things first.
What is SAML 2.0?
SAML 2.0 covers what is absolutely necessary in a modern IT environment: It creates the possibility to accomplish authentication across identity domains and to allow access to services based on an identity provider, which is not necessarily in my sphere of influence.
In short: an ideal construct for virtually mapping trust to other organizations, implementing partner access to services and yet retaining identity sovereignty for the respective organization.
SAML 2.0 is particularly popular in the public sector, as it allows users to log in to their organization’s IDP with their “local” credentials, making it easy to ensure single sign-on even to “non-organizational” applications (see eCH’s IAM reference architecture, and other blog posts on this topic).
SAML 2.0 was originally developed for the use case where I have logged on to a web application and want to log on to another web application with the same authentication.
Well, as is the case with such protocols, the circle of possible use cases is widening and what we often encounter today is the situation where SAML 2.0 is used to authenticate a wide range of different applications across multiple identity domains. To enable so-called cross-domain access, a federation with different IDPs and a central federation provider (FP) is constructed centrally using an identity provider or a construct based on SAML 2.0. The federation provider ensures authentication based on the IDPs of an organization (identity domain) using the credentials of a user within this organization.
SAML 2.0 can be nested very well to build a federation construct: A SAML 2.0 identity provider becomes a service provider of a “superordinate” identity provider.
The challenge of assigning rights
In such a situation, however, not only the problem of authentication arises, but also that of authorization, i.e. the assignment of rights to the individual service providers.
There are basically two integration patterns for the distribution of rights:
1) IDP of an organization manages the rights
In this case, the rights for an organization’s IDP are managed by the organization itself. In order to communicate the rights to the service provider, the rights or role information are sent as an attribute in a SAML ticket. This results in what is known as “just-in-time provisioning”. “Just in time” because the service provider only knows the rights at the time the user is authorized using a valid SAML ticket. In SAML 2.0, there is no provision for querying identity data at the identity provider.
2) The federation provider manages the rights and roles
In this variant, the federation provider has a central identity manager that ensures rights management centrally. A central directory with all identities and their rights is provided for this purpose.
When implementing federation constructs, it is now becoming increasingly apparent in practice that option 2) is proving its worth and is being used more and more frequently. There are good reasons why “just-in-time provisioning” (option 1) has so far been less popular in a federation construct. These reasons lie with the service providers, i.e. the applications and the development of these applications.
The world from the perspective of applications
Every application has its own universe of roles, rights and access control mechanisms. Harmonizing these is an impossibility. It is conceivable to use SAML 2.0 to transfer tickets, rights and role information to the individual service. But who specifies the naming of these rights and roles? The IDP or the service provider, i.e. the application? As soon as we move into a federated construct with several identity providers, it becomes a considerable operational effort to specify all roles and rights centrally on an IDP or to create a mapping between all the application roles and rights and keep it accurate.
Ability of applications to implement SAML 2.0
Another challenge is the direct integration of SAML 2.0 into the applications. Not every application and the development company behind it offers SAML 2.0 in its application out of the box. After years of LDAPS integrations and Kerberos/AD integrations, there is a certain skepticism in the development market towards SAML 2.0 or other authentication protocols such as OpenID. In the meantime, the IT industry has generally become accustomed to using an LDAP query to determine rights and roles in a central directory. In the case of a more complex federation construct, application developers often expect to be able to continue to do this using a central service. Whether it has to be LDAP remains to be seen, RESTAPIs seem to have become another de facto standard in application development.
Last but not least: Good old access governance
One of the most important aspects that is often forgotten in the discussion about “just-in-time provisioning” using SAML 2.0 is good old access governance.
In the case of “just-in-time provisioning” in a federated environment, no authority can determine beyond doubt whether or not the rights assignment is actually lawful. In other words: If a user has received rights from an organization with an IDP that he should not have and this organization lacks traceability of the assignment of rights, it may not be possible to prove beyond doubt who/when/why/by whom a user received the rights.
Access governance is only guaranteed in a federated construct if the access governance of all identity providers functions effectively (which is rarely the case in practice) or if a central identity management system is available for assigning rights with access governance.
The SES supports both integration patterns
With the extension of the USP SES IDENTITY module, SES supports the implementation of both integration patterns from a single source. With SES IDENTITY, it is possible to extend the IDP to include rights and role management and to synchronize the identities maintained in SES IDENTITY with their rights, e.g. in a central user directory. From there, the applications can use LDAPS to query rights and role information. This offers the advantage that the access governance of shared services can be ensured centrally. The multi-client capability of SES IDENTITY makes it possible to delegate identity and/or rights management to different partners. In addition to “just-in-time provisioning”, which SES already supports with its existing components, this provides a further, extremely powerful integration pattern.
We are happy to support you in choosing sustainable architecture for your project. Please do not hesitate to contact us.