Advancing Your Identity Management Strategy with the IAM Maturity Model

Federation is a specific type of SSO that enables organizations to integrate with applications without exposing critical systems or data by leveraging a trusted party to identify and authenticate constituents. The trust has been established between the systems ahead of time to verify this mutual exchange of information.

For example, companies who rely on third-party applications on a consistent basis can federate a set of applications to allow users one central point for authentication, such as entering a username and password.

So, Who Can Benefit from Federated Identity Management?

Federated identity management has significant benefits to organizations, particularly those who are in the beginning stages of an IAM program or those who are currently using or switching to cloud or SaaS-based applications.

A primary benefit of federation is to simplify the user authentication experience, saving time and headaches. Users login to the central point for authentication once and then seamlessly continue their day-to-day processes without having to constantly enter and manage separate credentials for each application.

In addition, organizations look to federation as a way to reduce administrative overhead. For example, there will always be employees coming and going, and perhaps your organization requires a password reset every 6 months. With federation, your administrative team has one central portal to make these updates, instead of within multiple applications for each user.

Finally, federation is used to increase the security posture in identity management and can even be combined with multi-factor authentication (MFA). When authentication is streamlined to one central location, very little information is shared with external applications, due to the trust established ahead of time. Adding MFA, such as a one time password or push authentication, adds an extra layer of protection from a security standpoint.

Where Does Your Organization Fall on the Federation Maturity Model?

As far as complexity of implementation, Level 1 is considered low hanging fruit. 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.

Level 2 is quite a leap, rather than a step, in the maturity model and mainly speaks to supporting multiple federation protocols.

In Level 3, security is increased by implementing multiple types of authentication methods with granular and adaptive authentication policies. And in the ultimate level, or Mesh, an organization is doing business with other businesses and with consumers, resulting in more SPs  and IDPs alike.

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. 

Building Blocks: Authentication Factors, SFA, 2FA, and MFA

An authentication factor is an "independent category of credential used for identity verification." In plain English, that means something that proves that you are who you say you are. As defined by NIST SP 800-63-3, the three factors that are identified as the cornerstones of authentication are:   

1. Something you know (e.g., a password).
2. Something you have (e.g., an ID badge or a cryptographic key).
3. Something you are (e.g., a fingerprint or other biometric data).

While there are varying definitions for the term, at Identity Automation, we define SSO as a one-time login that permits the user to seamlessly access their complete workstation. This initial authentication could be an ID/password challenge or it could be a passwordless challenge, such as using physical or biometric means of authentication. Once the user successfully confirms his or her identity, they will not be prompted for an additional login when accessing applications within the single sign-on environment.

In essence, SSO solutions enable users to access all of their applications using a single set of credentials and is all about improving your users’ productivity and user experience. 

Where Do You Fall on the Single Sign-On Maturity Model?

In Level 1, the Basic level of the SSO Maturity Model, organizations utilize Reduced Sign-On (RSO), which relies on directory services where accounts can be managed in one place. At this level, an organization has integrated many of their applications via Lightweight Directory Access Protocol (LDAP) to reduce the number of credentials an end user needs to remember. Essentially, the directory password is pulled and used to sign into applications that have matching credentials. For many organizations, this involves using simplified credentials, where users set the same password for multiple applications. 

In Level 2, the Advanced level of the SSO Maturity Model, the SSO solution is more sophisticated and uses technology to pass credentials through to applications, either as agent or agentless web SSO.

At the Advanced level, there is no need for password managers and Federation tends to start tying in with SSO. Organizations at this level have reached at least Level Two of the Federation Maturity Model. This means that when a user launches an application, he or she is redirected back to a central login page to put in their directory credentials. Upon successful authentication, the user is sent straight back to the application.

Level 3 of the SSO Maturity Model, the focus is on native SSO, or providing SSO for native applications on Windows platforms. At Identity Automation, we frequently see native applications used in education, healthcare, retail—basically any organization that has some sort of large enterprise resource planning (ERP) system. 

Level 4 takes everything in Level 3 and expands it to other platforms, including mobile. At Level 4, Intelligent, an organization supports SSO on every endpoint, including MacOS, iOS, Android, Chrome OS, Linux, and thin clients.

Where Do You Fall on the Delegated Administration Maturity Model?

In Level 1, also known as the Basic Level, a key characteristic is that administrators have the ability to perform simple delegation tasks, such as reset passwords. Without this primary characteristic, organizations would be considered at Level 0, meaning they have not yet implemented any delegation features or capabilities.

In Level 2, otherwise known as the Advanced Level, an organization expands on its initial offering of self-service capabilities by providing tools that empower business users to perform lifecycle management of external or sponsored accounts, such as contractors or visitors, and all self-service and delegation actions flow through to all connected systems. Another main characteristic resolves a common challenge organizations face: notifying workers of their newly created account credentials.

Level 3 of the Delegated Administration Maturity Model is comprised of two main capabilities. First, end users are empowered to help their peers based on birthright relationships (a user’s attributes or roles), such as a department, project, or class. Essentially, this allows business users to be a second line of support. Second, application owners are empowered with the tools to manage access to the applications they own.

Level 4, Intelligent, can also be broken into two main areas. First, organizations at this level have implemented some level of governance, another tenet of the IAM maturity model, maturing their delegated administration capabilities to allow full system visibility to application owners and business owners (non-IT users who are responsible for the line of business associated with an application or system). 

The second area of Level 4 speaks to granular controls that empower end users to give others the ability to act as their proxy. By defining proxy as policies, authorized users and administrators can view information as another user and perform actions on their behalf. 

Synonymous with automated lifecycle management (ALM), the goal of ILM is to automate identity processes across the organization’s environment. Automation ensures that identities across your organization’s disparate systems are in a state that matches your authoritative sources. Without an ILM engine, manually processing and managing identity changes and ensuring the appropriate actions are taken is very difficult.

While the primary focus of ILM is on the context of users, it can also refer to the identity management of any account that needs access. For example, ILM could be utilized for IoT devices and external services for service to service access.

Where Do You Fall on the Identity Lifecycle Management Maturity Model?

While our ILM Maturity Model starts with Level 1, an organization could actually be at Level 0, meaning there are no capabilities currently in place to manage user identities. Account provisioning is completely manual and done on an ad-hoc or reactive basis, so account details are prone to human error. In addition, onboarding, and the amount of time it takes to get a new employee online and productive, is often an issue.

On the other hand, organizations in Level 1 have begun automating account creation with scripts that are focused on basic account creation. However, as these scripts are created for specific purposes, they are difficult to generalize for repurposing. 

At Level 2, Advanced, an organization begins deploying vendor-provided tools to manage their accounts. However, these are single purpose synchronization tools, meaning they only work to automate account creation in that one particular vendor's product, and were not developed to provide complete lifecycle management. 

At the more sophisticated levels of the ILM Maturity Model, the processes become more and more automated. Organizations in Level 3 of the ILM Maturity Model have implemented an identity logic engine that automates processes across their entire ecosystem. The ILM engine centralizes all identity lifecycle management for a holistic approach, instead of various groups within the organization managing identities and lifecycle events within each application.

At this stage, ILM is fully automating what we call birthright access, which refers to the logic or rules whose criteria are met by the data received from authoritative sources.

While Level 4 is somewhat of a future concept, there are many groups and standards being published today that indicate the industry is heading in an API-driven direction in order to reduce the complexity of a complete ILM implementation. API-driven ILM refers to the target or downstream system which pulls identity and other business data using standard, restful APIs, giving internal and third party developers real-time access, rather than the organization having to design ways to push this data to the new system.