Federated Identity Management: Defining the Levels of the Federation Maturity Model, from Basic to Mesh

Recently, we discussed maturity models, and why we believe that federated identity management is the most logical first step in the Identity and Access Management (IAM) Maturity Model. As a refresher, maturity models can be used to evaluate the effectiveness of current capabilities and set a prioritization level when an organization is ready to advance its capabilities through maturity. 

When applying a maturity model to IAM, however, it’s important to examine the key tenets of an overall IAM strategy. Focusing on one area at a time creates a framework of smaller, digestible segments that help identify your organization’s current status on the maturity and capability scale, so you can determine next steps for moving forward. 

So, to continue our discussion about federated identity management, let’s take a closer look at the four levels we’ve defined as part of the Federation Maturity Model, keeping in mind that level 0—or absence of the capability all together—does exist. In the case of federation, Level 0 means users must log into every application they access with that application’s native login. Now, let’s dive into the details of the capabilities and characteristics in each of the four levels within the Federation Maturity Model.

Level One: Integration Between Identity Provider and Service Provider

As far as complexity of implementation, Level 1 is considered low hanging fruit because it has immediate benefits to both your organization and end-users. In this Basic Level of the Federation Maturity Model, the organization has an Identity Provider (IDP) in place with support for the SAML federation protocol and at least one additional federation protocol. Furthermore, the organization is integrated with at least one Service Provider (SP) or an application end-users access (think: G Suite, Office 365, etc.). 

As opposed to Level 0, where users must log into each separate application, with federated identity management, the trust has been established between the systems ahead of time to verify this mutual exchange of information and offload the authentication to the IDP. So, when the user goes to an application, they are redirected to the IDP to login. At that point, the user logs in with one set of credentials, and they are seamlessly granted access and redirected into the application. 

Level Two: Multiple Federation Protocols and IDP Chaining

Level 2 is quite a leap, rather than a step, in the maturity model and mainly speaks to supporting multiple federation protocols. In the world of federation, you have multiple protocols to manage, including SAML, OAuth, OpenID Connect, and WS-Federation. The protocol the SP is implementing drives the requirements for what your IDP needs to support. While it depends on your scenario, supporting one federation protocol is usually not sufficient. 

Level 2 also utilizes IDP chaining, which is unique to organizations deploying multiple IDPs. IDP chaining essentially enables users to authenticate with one IDP, but establish sessions with multiple, trusted IDPs.

Level Three: Multi-Factor Authentication

We’re all-too-familiar with the concept of logging into a website with a username and password. However, there may also be times we additional verification might be required, such as requiring a one time password if a user is outside an organization’s network or boundary. This is an example of multi-factor authentication (MFA), and in Level 3, security is increased by implementing multiple types of authentication methods with granular and adaptive authentication policies. 

Cross federation IDP comes into play in the MFA level as well. In Level 2, an organization starts implementing or supporting multiple protocols, but in Level 3, all access can be enabled with one login. A user only logs in once, and then, the IDP manages the different sessions with different protocols on the back-end. At this level, strategy is also in place to require SaaS providers to support Just-In-Time provisioning. 

Level Four: Session Management and IDP Proxying

Moving along to the ultimate level, or Mesh, an organization is doing business with other businesses and with consumers, resulting in more SPs  and IDPs alike. At Level 4, the complexities of mesh and simplifying administration come into play, as the organization is tasked with not only managing the IDPs, but the sessions involved in each as well. For example, let’s say an incident occurred where an organization’s administrator needs to remove access or kill all sessions tied to a particular user. While this is not typically achievable in federation today, it’s important to note as we evolve the federation maturity model. 

In Level 2, we discussed IDP chaining, which is typically internal with multiple IDPs within a larger organization. On the other hand, at Level 4, IDP proxying comes into play, eliminating the need for an organization to manage passwords and credentials for vendors and partners accessing internal resources. 

How does it work? With IDP proxying, an organization is providing services and has an IDP. However, based on who is accessing the IDP and establishing a session, there are policies in place to redirect that user to the appropriate IDP. 

Finally, through the use of virtual users, SPs can even be accessed without the need for static identities at all. The application accepts the user according to the assertions with a unique session, and when that session closes, the user no longer physically exists in that application. 

This concept has even been implemented in at least one scenario today. When accessing Amazon Web Services (AWS) using SAML, an AWS IAM user account is not required. Instead, a virtual user is created and the session is logged, but as soon as the session is closed, that user does not continue to exist. This is greatly beneficial to organizations, as it eliminates the need to manage yet another identity repository. 

What Are Your Organization’s Next Steps on the Federation Maturity Model?

Now that you have a high-level overview, you’re ready for an in-depth discussion to discover where your organization falls on the Federation Maturity Model, and the next steps to increase capabilities. 

Make sure check-out our on-demand webinar, Advancing Your Identity Management Strategy with the IAM Maturity Model: Part 1 - Federation, where IAM subject matter expert and Identity Automation co-founder, Troy Moreland, discusses federated identity management and provides practical and actionable insights into how to update and refine your organization’s federation efforts.

This webinar will serve as a tool to help you identify your organization’s current status on the maturity and capability scale, as well as identify areas of focus with the Maturity Model Scorecard.