Recently, we discussed the Identity Lifecycle Management (ILM) Maturity Model, including how ILM fits into a modern identity and access management (IAM) system and benefits organizations as a whole. ILM centers around the creation of identities, taking appropriate actions for any changes, and the removal of identities across all the services and applications end users access within an organization's ecosystem.
Our ILM Maturity Model has four levels, starting with basic capabilities in Level 1 all the way through to automated, API-driven lifecycle management in Level 4. Previously, we discussed the characteristics of the first two levels.
As a refresher, in Level 1 an organization has accumulated a number of homegrown scripts that are focused on basic account creation to partially automate a portion of ILM. In Level 2, an organization begins deploying vendor-provided single-purpose synchronization tools to automate account creation in that one particular vendor's solution.
Let’s continue by jumping into Levels 3 and 4 of the ILM Maturity Model, where ILM processes become more and more automated.
Level 3: Centralized Lifecycle Management with Flexible Engine Logic
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. In the case of the employee, examples of lifecycle events include: being hired, transferred, promoted, terminated, rehired, name changes, conversions from employee to contractor, and vice versa. Without an ILM engine, these events must be reviewed on an application by application basis to determine what actions must be taken for each of these applications.
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. Implementing the ILM engine provides the organization with direct integration to authoritative sources, or any source system that is authoritative of identities and their attributes. This means organizations in Level 3 are not just concerned with Active Directory, they also need to implement the rules and logic to take the appropriate actions for each application based on the lifecycle events driven from authoritative sources. If all data in authoritative sources are correct, the data is relied on to drive events. Additionally, the data is compared to a rule base, and that rule base is applied to all systems and identities in the organization.
Specifically for employees, authoritative sources could refer to an HR system, payroll system, or even a combination of the two. The HR system hosts data, such as the user’s position, department, location, manager, and more. In education, the authoritative source is the student information system (SIS) and in healthcare environments, think electronic medical records (EMR). The ILM engine reviews the data and attributes found in the authoritative system to determine the structures and groups in which to place the user identity and the applications the user should and should not be able to access, along with the appropriate permissions. For example, if an employee moves from IT to finance department, the ILM engine knows to remove the user’s IT permissions and grant them permissions to finance applications.
The greatest benefit of centralizing the entire lifecycle process with an identity logic engine is that numerous events are automated, not just the onboarding aspect. Additionally, if you have a complete ILM implementation in place, the audit process is simplified because it’s easy to demonstrate which users have access to which applications and resources. On the other hand, if your organization has limited ILM capabilities or is relying on manual processes, you’re going to have to go into each application individually, correlate identities with applications, and then determine the level of access and how it was granted.
It’s important to make sure the engine is flexible enough to implement the logic required for your organization’s business processes, instead of a rigid engine where processes must adapt due to limitations of the tool. While a flexible engine still may require slight process modifications, organizations certainly shouldn't have to completely change their business logic to conform to the tool.
The larger the organization grows, the more applications are being supported based on end user access, and the greatest challenge is when the organization starts looking at other systems to integrate. You have to learn the new system’s protocols, its application program interfaces (APIs), and capabilities, which can be very difficult. Organizations looking to mature to from Level 3 to 4 often question how to simplify integration and become more efficient.
Level 4: API-Driven Mentality to Support Growth
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.
Let’s say every application in your organization’s ecosystem is integrated using the ILM engine, so data is being ingested from the source and pushed out to all of the targets. That pushing is a unique set up for every system. This can quickly get complicated, depending on the amount of applications and the level of disparity among them.
In order to help simplify this complexity, there are tools on the market that have sync capabilities; however, these tools do not always reflect the capabilities of the application or system. Typically, sync tools offer either a one time bulk load where it’s up to you to handle everything else or they provide some sort of mirroring, which doesn’t implement full lifecycle capabilities. Sync tools also do not handle other portions of lifecycle events, such as changes and deprovisioning. Furthermore, many of these tools require the business processes within those systems to abide by how the data is essentially “force-fed,” so you can’t implement the processes you’d likely want to use.
The biggest barrier to implementing ILM across your organization’s ecosystem is the high level of disparity across applications and services. For example, organizations often run into legacy, proprietary, or closed systems that don't provide an interface for direct interaction.
For generic legacy systems, there are typically adapters or connectors available, but for worst case scenarios, files must be created and then pushed to those applications for their data consumption. This isn’t ideal because it adds a major disparity, whereas consuming the data from the authoritative sources directly is typically more straightforward.
On the other hand, HR systems are typically purpose-built to include mechanisms that expose that data. This data could be pushed through as text files, but usually, it can be accessed via the backend database, or better yet, more and more authoritative systems are starting to provide web service APIs.
There are an unlimited number of downstream target systems, each is unique. Rather than building each one of these integrations, providing a standard restful API is becoming the de-facto means for allowing integration or data synchronization between systems.
This trend is being seen across industries. For example, there’s a web service API standard for financial organizations to exchange data, known the Financial Data Exchange. There’s also the Parcel Data Exchange for interactions between parcel shipping companies, such as the United States Postal Service (USPS) and FedEx. In the education space, there’s a standard known as OneRoster that describes exactly how to share all roster information between disparate systems. There are also open initiatives, such as the OpenAPI initiative and the JavaScript Object Notation (JSON) API standard.
The reason these API standards are being developed is because the complexity of sharing data between disparate systems is a global problem. Whether it’s identity or non-identity data, API standards are a growing point of interest, and ILM is certainly one technology that benefits from this standardization.
For a real world, consumer-facing example of API-driven service integration, the cloud service Zapier is a tool that provides integrations for non-technical and end users to connect disparate cloud services.
Take Your Identity Lifecycle Management Strategy to the Next Level
While ILM can have a number of paths to get to a desired state, some work more efficiently than others and provide in-depth coverage of identities that many organizations might not realize should even be included in their ILM strategy. Levels 3 and 4 of the ILM Maturity Model are very sophisticated and automated in that there is very little human intervention. However, the majority of organizations are still at Level 1, where technical teams are constantly writing new scripts to keep up with the demand for ad-hoc requests. Without an ILM engine analyzing events and taking the appropriate actions in downstream systems and applications, other tenets of IAM, such as access management, cannot be utilized to their full potential.
Interested to find out where your organization falls on the ILM Maturity Model? Then watch our on-demand webinar: Advancing Your Identity Management Strategy with the IAM Maturity Model, Part 5 - Identity Lifecycle Management, where IAM expert and Identity Automation Co-Founder, Troy Moreland, provides insights into how to evaluate your organization’s current ILM maturity level. In this webinar, you will also gain actionable steps on how your organization can mature through each stage of the ILM Maturity Model.
Comments