Part 4: The Workflow Engine

Part 0: What Modern Identity Management Solutions Should Look Like?

Part 1: The Datastore

Part 2: Connectors

Part 3: The Sync Engine

Part 4: The Workflow Engine

Part 5: The Customers and What to deploy?

Part 6: Engineering challenges - Connectors

Part 7: Consulting challenges – Why do most RBAC / ABAC Deployments Fail?

Part 8: IAM People Management challenges

Part 9: The Unspoken Realities of Identity Management

Part 10: Confessions of a Former Hacker: From Script Kiddie to Identity Management Advocate

Part 11: What Are the Gaps in Current Identity Management Solutions?

Part 12: How to Deliver IAM Solutions While Keeping Everyone Sane

Part 13: Identity Management in the era of AI and LLMs

Part 14: Future Trends in Identity Management for 2025-2030

While the sync engine handles data transfer between connected systems, including basic transformations like concatenating last and first names into a display name, most business logic is offloaded to event and policy-driven workflows. Identity and Access Management (IAM) workflows extend beyond traditional Joiners, Movers, and Leavers scenarios. They encompass tasks such as calculating unique values, preventing the reuse of previous values, augmenting user properties from other sources like locations or business roles, sending various notifications, and handling verifications and approvals through self-service portals.

Workflow Types

When designing the workflow engine, it is essential to support both event-driven and policy-based workflows. Event-driven workflows are triggered by changes to an object, while policy-based workflows are initiated by new policies or transitions in and out of events caused by temporal conditions defined in policies.

Workflows can range from simple, single-threaded processes to complex sequences supporting partial and conditional execution of steps. These steps, known as workflow activities, can be categorized into different types based on their function.

Types of requests

CRUD operations

·???????? Events related to Create, Read, Update, or Delete operations involve a caller, a target, and a payload. This triad defines most policies, such as determining who is allowed to perform specific actions.

·???????? A caller can be a specific object, a set (akin to a group), or an object related to the target, such as a manager, owner, supervisor, or member.

·???????? A target may also be a set, like "All Groups", "All Full-Time Employees" or "All Cashiers in a specific branch". Policies may define allowed actions and specific properties, such as reading all properties, adding but not removing multi-valued references of "members" or updating "displayName".

·???????? Microsoft Identity Manager (MIM) Service extends this logic with "Target set before" and "Target set after" definitions. For example, a policy with "target set before" as "All Full-Time Employees" and "target set after" as "All Contractors" applies only if the target transitions from the former to the latter. While being an extremely flexible and useful, this approach forces MIM Service to calculate all potential transitions IN and OUT from all sets in advance, even prior to committing requests to its database. This is very time-consuming operation. I would offload ‘Target set after’ verifications into workflows to improve performance.

Each policy should also offer an ability to assign workflows to have necessary verifications, approvals and post-processing actions. According to their types, workflows are to be executed either prior request is committed to a database (or sent via message bus, authorization) or after a change is made (thus, post-processing or action workflows).

Transition IN / OUT events

Transitions in and out of sets are typically triggered by underlying reasons, such as changes in temporal sets with criteria like "resignation date prior to 14 days from today". These transitions must be recalculated at least once a day to apply related policies and workflows. Unlike standard requests, system-generated events skip the authorization phase, allowing only action workflows to be linked.

Types of workflow activities

From the request lifecycle perspective there are 3 workflow activity types available:

Authentication activities

·???????? These activities are less common and primarily used for self-service password reset operations. They authenticate an anonymous user through mechanisms like passwords, OTPs, QA, or authenticator apps. For other operations, authenticated callers are assumed.

The goal is to ensure that a caller is who they claim they are to continue request processing.

Authorization activities

·???????? These activities gather necessary approvals, conduct checks (e.g., SAP GRC/AC integrations) or validations, e.g. ’vendor account end date extension not to exceed 180 days from today’, and enforce delegated administration with scopes defined like ‘current shift-manager with M3 approval level or above, working in their primary location, having authorization to release SWIFT 5xx USD transactions up to $100k for MSFTUS3NXXX BICs’.

They ensure requests adhere to corporate policies before further processing. After successful completion of this phase, request is accepted and committed to database or sent via message bus.

Action activities

·???????? The most prevalent type, action activities handle post-processing asynchronous events. They manipulate objects and properties, construct display names, update linked objects, send notifications, and perform cascading updates.

The Platform

With policies in place defining permissions and authorizations, and workflows outlining the actions to be taken, the next essential component is a robust platform to host these workflows.

Platform Requirements

The choice of platform is flexible; what matters is its ability to scale, restart failed workflows, and offer manageability alongside basic MIMWAL-like functionality.

In 99% of cases, workflow failures stem from external calls, such as executing a PowerShell script, making an LDAP call, or sending a SCIM request. To mitigate this, external calls should be avoided within workflows, with connectors being utilized instead.

The remaining 1% of failures typically result from resource outages and deadlocks or race conditions, which can be partially resolved by introducing asynchronous updates through message bus events with guaranteed delivery mechanisms.

Out-of-the-Box JML Templates

A common request during the FIM/MIM era was for policies and workflows that implemented basic Joiners, Movers, and Leavers (JML) scenarios. MIM lacked out-of-the-box solutions, often requiring costly consultant engagements, deterring smaller organizations. Fortunately, Entra ID and its IGA features now provide pre-canned scenarios, making the availability of basic JML scenarios out-of-the-box crucial for modern Identity Management solutions.

IGA Workflows

A flexible platform supporting policies, sets, and workflows, with the extensibility to run custom workflow activities, and an underlying Graph DB with a metadirectory, enables the development of comprehensive governance features. These can include:

• Attestation or Access Reviews: Periodic reviews to ensure that access permissions are appropriate and compliant.
• Access Packages or Business Roles: Bundled sets of access rights for specific job functions or business roles.
• Role Mining and Prevention of Toxic Privileges assignments: Identifying and mitigating risky combinations of access permissions.
• Self-Service Portal with Custom Forms and Business Processes: Enabling users to manage their own access requests and approvals.
• Integrations with External Risk Management and Ticketing Systems: Seamlessly connecting IAM processes with broader IT and security management systems.

By leveraging a versatile and scalable platform, organizations can implement a comprehensive and effective Identity Governance and Administration (IGA) system, addressing both current needs and future challenges.

Previous: Part 3: The Sync Engine

Next: Part 5: The Customers and What to deploy?