IGA Capability: Identity Workflow Automation
Alternative names
-
Workflow
-
Identity workflow management
-
Remediation
Identity Workflow Automation Functions
-
Remediation of policy violations. An action taken to remedy a policy violation, getting system back to the state of full policy compliance. The action follows up on a detection of policy violation. Remediation actions are often manual actions taken by a human user.
-
Case management. Keeping a record of cases, specifying a problem that needs to be resolved, usually in an unstructured way. Cases are usually used to record policy violations, role definition problems, high-risk situation and so on. The case often assumes that there is no pre-defined algorithm or workflow pattern that could be used to resolve the problem. The solution is provided by the users, cooperating and communicating on the case.
-
Process management. Keeping track of processes, with an aim to resolve a specific problem in a structured way. The processes are usually based on human interaction (workflow). This approach assumes that there is a structured, pre-defined pattern of interaction of specific users that leads to problem resolution.
-
Escalation. Ability to re-assign a case or process step to a new assignee in case that the original assignee did not take action within a specified time. Escalation is often used to bring attention of managers and leaders to an issue that is not resolved within its usual time-frame.
-
Notifications. Ability to inform a user that a specific action has taken place. E-mail message informing user about new accounts or entitlements is perhaps the most common form. Yet the notifications may be implemented by a variety of ways.
Overview
While identity management strives for automation, there are still tasks in identity management and governance that must be done by human beings. These are usually decisions that cannot be made automatically, tasks that do not have algorithmic description, or just a simple notification, letting users know about the progress of a task.
Many processes in identity management can be automated, and in fact, automation is one of the primary tools of identity management and governance. However, there are several cases that cannot be easily automated due to their very nature. Most of such tasks are meant to handle situation when something goes wrong, something that cannot be fixed by an automatic action.
Remediation of policy violations are perhaps the most common case for manual workflow. Let’s suppose that we have a policy that every project in our organization must have at least one manager. That is a very natural policy, requiring that there is always a person responsible for the project and all the resources associated with it. However, what should IGA platform do, when a project manager leaves the company? Operation that deletes or archives the identity of the project manager is causing policy violation, as there will be a project without a manager. However, IGA platform cannot stop the operation, it cannot refuse to delete the identity. IGA platform cannot even postpone the operation, as there may be good reasons to immediately disable all access of that person. Yet, executing the operation leaves the system in a state of policy violation.
This example illustrates relatively common problem in identity governance, a problem that strict enforcement of policies cannot solve. The usual solution is to proceed with the operation that violates the policy, accept the fact that there is a policy violation, and start a remediation action to get the system back to state of compliance with the policy. Many remediation actions are manual action that need to be done by a human. In the case of missing project manager above, a human has to make a decision to nominate new manager for the project, or to close the project. There are many tasks in identity governance that need human interaction, such as:
-
remediate policy violation,
-
add missing role definition,
-
improve existing role definition,
-
resolve dangerous privilege accumulation,
-
address high-risk situation,
-
eliminate redundancies (e.g. almost-duplicate roles).
While the actual action or actions have to be done by a human, IGA system has a responsibility to monitor progress of the task, to remind participants that the task needs to be done, to report the task and provide similar support and management functionality. This is known as identity workflow automation.
IGA platforms usually use two approaches for workflow automation:
-
Process-based approach is using pre-defined sequence of steps. The process defines what should be done, who should do it, in what sequence and under which conditions. It is essentially an algorithm, composed of human interactions. General-purpose workflow engines are usually used to manage the process, business process definition languages (such as BPMN) are usually used to specify such process.
-
Case-based approach relies on unstructured or semi-structured cooperation to complete a task. A case is similar to a trouble ticket used in ITSM systems. It describes the problem that needs to be resolved, however, it does not specify a predefined steps to resolve it. The person or persons that the case is assigned to must figure out the specific steps or operations to resolve a case. A case is initially assigned to a particular person or a group based on simple rules. However, it is not expected that such initial assignee will be able to complete the case. The case is often re-assigned to a different person, several persons co-operating on resolving the case, commenting and interacting until the problem described by the case is resolved. While most of the work and information regarding a case is unstructured, the case almost always has a structured status indicating the progress (open, on hold, resolved, closed and so on).
Traditionally, IGA platforms relied on process-based approach, in a hope that every situation can be formalized and an algorithm can be specified to resolve it. While this may be formally true, the specific algorithm is seldom known at the time of IGA platform deployment. In fact, it is seldom known at all, as it may be slightly different for each specific case. Therefore, many practical IGA deployments tend to utilize a case-based approach, relying on unwritten knowledge of key people in the organization to resolve the cases. The process-based approach is used for some special purposes, such as on-boarding and off-boarding processes.
Some functions are common to both approaches, such as progress monitoring and escalation functionality. Escalations are usually triggered automatically, when the problem is not resolved or step in the process is not completed until a specified time interval. Escalations often rely on organizational structure management, as the task is often escalated to a manager.
Notification functionality is also considered part of workflow automation capability. Purpose of notifications is to inform users that an action has taken place. Perhaps the most common form of notifications is an informational e-mail message informing the user that new accounts were created, or new entitlements were assigned. However, notifications can take many forms: e-mail messages, mobile text messages, in-app notifications, chat messages and so on. Notification often containing custom messages, often requiring multiple language versions.
Identity workflow automation capability is often a "catch all" tool, meant to resolve all the problems that other parts of IGA platform are not able to resolve. However, the primary goal of the IGA should be automation of the management and policy processing, not just automation of human-based workflow. Formalization of policy concepts, such as definition of roles, machine-processable policies and rules are necessary for successful IGA deployments. Workflow automation should be used only for steps that computer cannot execute automatically.
Workflow automation brings yet another challenge: long-term maintenance of IGA solution. Automated workflow processes require surprising amount of customization, especially when process-based approach is used. The processes need to be modeled, expressed in a form of algorithms, using a high-level programming language. As organization change, the processes tend to change as well, requiring constant maintenance of the code. While in theory the processes can be created and maintained by (non-IT) business people, the reality is often different. IGA processes are usually burdened with identity management concepts, data structures and implementation details. Creation and maintenance of the processes almost always require expert skills in identity management and governance, making it a very expensive part of IGA solution operation. Moreover, heavy customization is usually a major obstacle for system upgrades. This is especially dangerous for IGA platforms that are heavily based on general-purpose workflow engines. Upgrade of such systems usually requires complete re-implementation of all customizations. Case-based systems are usually much easier to maintain and upgrade.
Terminology Notes
When it comes to terminology and taxonomy established in the industry, there is a major ambiguity as to the scope of the identity workflow automation capability. Some authors tend to include almost all human interactions in workflow automation, including access request approval processes and manual fulfilment processes. While, strictly speaking, both approvals and manual fulfillment steps are "workflow", their purpose and structure are vastly different than all the other manual steps. Approvals and manual fulfilment is very structured process, it is almost always algorithmic, it requires significant amount of knowledge about structure of identity resources, policies and roles. Therefore many IGA platforms have a special-purpose implementation for such processes. Moreover, such processes have their very specific business purpose, matching the purpose of access request capability and fulfillment capability respectively. Therefore, we do not consider access request approvals and manual fulfillment to be part of identity workflow automation capability. Despite that, there still may be implementation overlap with other capabilities, especially access request, fulfillment and certification. It is likely that IGA platforms will use the same mechanisms for management of cases, commenting and similar interactions, escalations and so on.
Workflow Engine Notes
Identity workflow automation often relies on techniques and technologies developed for general-purpose enterprise workflow automation. Many IGA platforms even contain an embedded workflow engine, programmable using a general-purpose high-level business process language such as BPMN. Such embedded workflow engine are usually heavily customized to support identity-related concepts, such as concepts of access request, role, entitlements, account and identity attributes. Users participating in such workflows are supposed to use IGA platform and its special-purpose user interface to interact with the workflow engine.
Such an approach makes sense in smaller organizations that do not have their own enterprise workflow automation platform already deployed, and do not plan deployment of such platform. For organizations that already use workflow automation platform it would make much more sense to integrate IGA workflows into an existing platform. Unfortunately, such integration possibilities of existing IGA platforms are currently very limited.
The IGA-embedded workflow engine approach also makes sense in deployment with heavy pressure for initial cost efficiency. However, maintenance of such a solution may become very expensive in the long term, especially for solutions that heavily rely on embedded workflow engine, or solution with heavy customizations.
Relevant MidPoint Features
Following midPoint features are relevant to this IGA capability:
| IGA Function | MidPoint Features |
|---|---|
Remediation of policy violations |
|
Case management |
|
Process management |
|
Escalation |
|
Notifications |