From MIM to Modern Identity: The Future of MIM Part 2

This is the second part in our Future of MIM blog series, examining moving from MIM to the cloud.

In Part 1 we discussed the future of Microsoft Identity Manager (MIM) and answered frequently asked questions about the various paths forward. In this blog, Part 2, we will examine how modern identity and zero trust can and should be considered as organizations plan for future identity management programs independent of MIM. Part 3 examines key considerations for building strong compliance and governance programs.

Microsoft Identity Manager

The original purpose of MIM and its earlier iterations was to group disparate data sources and their objects together to form a single representation of those objects. The objects could be users in an address book, where phone numbers come from a telephone system and email addresses come from the mail system, and MIM can group these together to form a holistic view of a user and their data. More importantly, MIM was also used to form a complete ILM system for an organization. In most organizations where MIM was utilized, this was its primary use.

Legacy Identity Lifecycle Management

Identity lifecycle Management (ILM) is the process of automating and managing the entire digital identity lifecycle processes for their protected IT resources.

MIM is especially good at this for legacy environments. For example, MIM can be connected to an HR system for an identity source, and then users can be provisioned to enterprise applications based on designed criteria. For some situations, MIM can also provision roles to these applications for each user, based on some type of designed workflow. This is also beneficial for legacy applications, since MIM has the capability to synchronize passwords, enabling each application security plane to be managed centrally.

Modern ILM

Microsoft Azure provides secure services and applications based on modern security protocols. This security utilizes a centralized Identity Provider (IDP) that controls authentication and authorization, and modern applications and service providers trust the IDP for that control. This security is based on tokens – an ID and/or an Access Token. The presence of this token indicates that the user has successfully authenticated and is authorized to access the application or service.

Azure-protected applications permit Azure to do additional authorization based on the received token. For example, an Access Token contains information on what the user that obtained the token can do within the application. A protected Application Program Interface (API) may have read access, read write access, etc. – whatever the API has defined for its security. This means that not only does the IDP need a security principle for the authenticated user, but there needs to be a corresponding object that uniquely identifies that user in the application that the IDP trusts. Azure provides the mechanism to be able to deliver properly formatted tokens for this purpose.

from mim to modern identity, ilm, identity lifecycle management, microsoft identity, zero trust

This security model is different than the legacy security model for which MIM was utilized in ILM. In legacy applications, each application was responsible for its own authentication. This authentication had no security integration with any other application’s authentication. In Azure, authentication is centralized, and only authorization is synchronized.

Zero Trust Model

Azure easily enables organizations to implement a Zero Trust model. ILM processes also should follow a Zero Trust model. A Zero Trust model has these three characteristics:

  1. Verify user access explicitly (Responsibility of the IDP)
  2. Least privileged access (IDP for on/off application access and defining application roles in access tokens, application responsible for enforcement)
  3. Assume breach (Token verification by applications)

Integration of Zero Trust with ILM

The integration of Azure’s Zero Trust model with ILM is straightforward:

  1. Creation of a user security principle in the IDP only when application access is needed (allows verification of user explicitly and least privileged access) – Create a user within the IDP only when trusted applications are needed for the user
  2. Control of assigned applications (least privileged access) – Assign the least privileged access to the user via assigned application roles
  3. Creation of the security principle in the assigned application (least privileged access) – Create the user within the application only when application access is needed
  4. Assignment of application roles via IDP – access tokens (least privileged access) – Assign roles via the IDP that align with user roles defined within the application
  5. Assignment of application user roles in application (least privileged access) – Assign roles via the application that align with user roles defined within the IDP
  6. Applications are responsible for:
    • Respecting access token roles and scopes (least privileged access / assume breach)
    • Requiring the utilization and verification of tokens with the IDP (assume breach)
    • These two are usually not controllable by an organization unless they develop their own applications.

Azure – ILM and Zero Trust

How does Azure natively handle ILM management and Zero Trust?

  1. Azure provides some connectors that will integrate with external service-oriented architecture (SOA) systems for user creation. In addition to these, Azure AD Connect can provision users from an on-premises AD environment.
  2. Applications can be assigned to users based on groups.
  3. Applications can be assigned access using just in time Privileged Identity Management.
  4. In addition to assigning access, applications may expose roles when integrated with Azure. These can be assigned by groups as well. In more advanced scenarios, roles can be defined via integration logic.
  5. Enterprise applications also expose the ability to provision users to applications if the application provides an interface for this. This can be controlled via groups.
  6. User roles can also be provisioned on a per application basis within Azure if this capability is exposed via the application and can also be controlled via groups.
  7. Tokens have a defined lifetime and are signed and verifiable. In addition, appropriate scopes and roles can be defined within the access token. The application then verifies and allows appropriate access based on this token.

Azure ILM and MIM

Is MIM suitable to centrally control these ILM processes in Azure?

MIM is a synchronization engine and is fully capable of some of these requirements.

It can provision users from a source (like HR) and deprovision users to the IDP. In fact, MIM may be required if Azure AD Connect is in place, or a connector is not available from Azure for the SOA.

MIM can control groups, and if the IDP utilizes groups for application assignments, then it can do this as well.

Beyond this, MIM integration gets more complicated.

When an application is defined within Azure, application roles are typically defined/exposed by the application. Through creative API and PowerShell integration, MIM could control this as well.

Bifurcated Management

However, when applications increase in number the complexity of this integration grows exponentially. One could assign roles based on groups, but these role assignments would then be defined on Azure, which bifurcates the management process. It is common for our clients to have dozens and often more than 100 business applications, so our approach to a solution has to include an analysis of the effort to manage the environment in production.

Role Management and Discovery

Proper application access management may require role discovery and possibly an additional connector for each application defining the appropriate user assignments. This can be extremely complex in MIM, especially if new application roles are exposed, or there are many roles. And again, our customers may have dozens or hundreds of applications in their environment.

It is possible that an organization is required to manage all of these, as well as governance for many applications.

For granular control and complete enterprise governance, a third-party tool is needed that goes beyond basic Azure ILM processes, in which all the above and more is incorporated. Our next blog installment will examine governance and compliance considerations for enterprise organizations.

Where do you start?

If you have read this blog, odds are you’ve been using MIM for a long time. Moving to a zero trust model in the cloud is a substantial change, both conceptually and practically.

Every customer has a unique situation, and the best course of action is not the same for everyone. While Oxford Computer Group (OCG) is a strong Microsoft partner, our expertise and experience are wide – we do not rely on software sales for our income, and we aim for an impartial view of the best way forward. We are all about enabling the cloud, but we recognize that this is not the whole story. If your organization needs guidance on developing and deploying a path to modern, secure, and scalable identity, contact OCG.

Continue reading with Part 3, “Securing Modern Identities with Strong Governance.” Read Part 1 here. 

Want to learn more about moving from MIM to the cloud? Check out the recording of our Q&A webinar here.