IGA Capability: Access Requests
Alternative names
-
Role request and approval
-
Role request process
-
Approvals
Access Requests Functions
-
Access request user interface. User interface for common users, allowing to compose a request, usually containing roles. User interface often follow electronic shopping (shopping cart) paradigm, organizing available roles in categories, user-friendly role search, request policy validation, and so on. Support for request state tracking after request submission. Requesting unassignment of roles.
-
Management of approval schemes. Definition of approval schemes, definition of approval levels/stages, approver groups for each level/stage, optional approval levels/stages and so. Definition of schemes per role type or group, scheme variations for sensitive roles, risk-based approval schemes and so on.
-
Execution of approval processes. Execution of approval schemes: driving access request through approval levels/stages. Human interaction with approvers, presenting the request in human-friendly form to approvers. Handling of approver decisions (approve/deny), free-text communication (approver comments). Optional forwarding of requests to be processed by another person.
-
Maintenance of approval accountability record. Record of the access request and approval process for accountability (auditing) purposes. Recording the metadata (who has requested, who has approved, when and so on).
-
Immediate fulfillment of approved requests. Immediate creation of account, associating them with entitlements according to results of request and approval process.
Overview
Access request is a process for controlled, user-driven assignment of roles and entitlements to users. It is usually implemented as request-and-approval process to assign roles to users. The roles are usually requested by the user using a self-service user interface. The request is then driven through a series of approval steps. When approved, the roles are automatically assigned to the user.
First step of the process is the request. The complicated part of this step is a selection of the things to request. The request usually specifies roles to be assigned to the user who is creating the request. Requesting roles makes a lot of sense. Roles, especially business roles are closely related to business, therefore the requesting user has some chance to understand the concepts that roles represents, hence a higher chance that the request will be meaningful. Also, roles usually have the right "size" for a request - they are not too "small" (very fine-grain entitlement), and not too "big" (too many privileges). However, there are usually thousands of roles even in a mid-size IGA deployment, therefore presentation, navigation and selection of the roles is a challenge.
Most IGA platforms seem to adopt a shopping cart approach to role selection. The roles are presented in a similar way as electronic shops present their goods. There are categories, recommended items, popular items and other visual aids meant to assist a user to select appropriate roles. Role categories are almost always based on the structure of role catalogs. The user can browse the "shop" and place suitable roles into a shopping cart. IGA platforms are usually considering role policies when presenting the roles and the cart. For example, in case of separation of duties (SoD) policy, conflicting roles are marked in the selection, or a warning is issued before the request is placed.
The request is usually made for "myself", which means that the person requesting the roles is also the person that will get the roles eventually. Alternatively, there are cases when the request is done for another person, for example a team leader requesting a role for a team member. Both approaches are used in practice.
There is also a very attractive option to request the roles that somebody else has, usually meaning a colleague of the requesting person. While this option can make the life easier for an ordinary user, it is a very controversial option. Firstly, the usual practice is to request all the roles that the other person has, without any real consideration whether all the roles are necessary. This is a significant problem with respect to least privilege principle, as it may lead to uncontrolled proliferation of role assignments. Secondly, this leads to repetitions (redundacy) in role assignments. If such a request is approved, we will end up with two users having the same set of roles. When job responsibilities of one person would change, it is very likely that role assignments of the other person will need to be updated too. Such situation makes the system harder to maintain, and every such role assignment "as somebody else has" makes the situation worse. The right thing to do in this case is to create a new role from the set of privileges of the "other person", reviewing whether the set of roles makes sense from both business and security perspective. Then the new role should be assigned to both persons. Sadly, there is very little support for this approach in existing IGA platforms.
Second step of the process is approval of the request. While some requests can be executed without an approval, vast majority of the requests require an approval by a human. This step is very difficult to automate. After all, if there is an algorithmic rule to give user a role, such rule could usually be applied pro-actively, without any need for the user to request the role. The whole point of access request process is that the rules of role assignment are not know, or they cannot be implemented algorithmically. Many approvals are done on "looks good" basis, without adhering to any rules, an approver judging whether the request makes sense from business perspective. The rules of "what makes sense from business perspective" are usually unwritten, non-algorithmic and ever-changing. Therefore the decision has to be made by a human brain, or, more often, by human brains. There are often several levels (or stages) of approvals. First approval level is usually a line manager (direct supervisor) of the requesting user. This approval level is usually implemented for two reasons. Firstly, it acts as a filter to quickly stop excessive or meaningless requests, distributing the filtering work among a large group of users. Secondly, it is a form of information for the manager that such request is taking place. Second level of approval is usually approval by a person responsible for the role or the application to which the role gives access (role/application approver). Third approval level is usually optional, reserved only for special or sensitive roles. This level is usually processed by information security staff. The levels are usually executed in sequence. E.g. second level of approvals is only started when first level is processed. This approach makes the process longer, yet it reduces load on higher-level approvers.
The approval scheme (approval levels and approvers) usually differs for each role or role group. Some roles may need no approval at all. Other roles may only need a single-level approval. Most roles will probably need approval by a manager and business owner(s) of involved application(s). Some roles may need additional approval by security staff. Specific set of approval levels and approver groups may be different for every role. The actual scheme would ideally be context-aware and risk-based, e.g. requiring approval by security office even for low-risk roles, in case that the total risk that a requesting user accumulates form existing roles is too high.
Approval process is manual process, involving human interaction. There is often some kind of free-text communication involved, such as a requester writing down reasons for requesting access, approver commenting on the decision and so on. Some processes allow for request to be "forwarded" to another person for processing. Therefore, there may be relatively complex trace of people, comments and decision that is usually recoded. Such record, together with additional metadata, is an important accountability mechanism. It may be an evidence later on when the assignment is re-certified, or in case of incident investigation. Even in a normal operational case, the metadata are important visibility and diagnostic mechanism, quickly showing who has requested the access, who has approved it and when that happened.
Obviously, the approval process is far from being simple. There is surprising amount of identity-specific logic in the approval process. Apart from dynamic computation of the approval scheme, the original request needs to be split to smaller parts, potentially routing each individual role through different set of approval levels and approvers. The request needs to be merged at the end of the process, correctly reflecting parts of the request that were approved and the parts that were rejected. Many IGA platforms are trying to implement the approval process using general-purpose enterprise workflow engines. However, such attempts either fail to deliver the required level of flexibility, or end up as very complex and difficult-to-maintain solutions. This is further amplified by the visualization difficulty that impacts almost all identity management systems. As identity management concepts can be quite complex and confusing, it is not easy to visualize what is being requested, what part of the request is being approved, and in what context was the request made. General-purpose workflow engines are not designed to handle such complexity. Therefore specialized, identity-aware user interfaces provide much better user experience.
Third step of the process is role assignment. The parts of the request that were approved has to be fulfilled. Most IGA platforms are immediately fulfilling the requests using their integrated fulfillment mechanisms. Some platforms are able to fulfill the request only when all the approvers of all parts of the request made a decision. However, it means that a single approver can hold back a big request. Other platforms have an option to immediately fulfill parts of the requests that have been approved, not waiting for roles with pending approvals.
The goal of access request process is assignment of roles (and possible other entitlements) to users. However, if there is an efficient process to add new privileges to users, the privileges will grow, up to the point of dangerous privilege accumulation. It is paramount that the cumulative effect of access request process is counter-acted by an inverse process, a process focused on removal of entitlements that are no longer needed. Naive IGA solutions often rely on manual work of system administrators, or manual, paper-based processes. However, such mechanisms are nowhere near the efficiency of access request process, never able to remove the roles as fast as they are added. Perhaps the only practical solution that could counter-act the access request process is access certification. Efficient access certification is almost always an absolute necessity in case that access request process is used.
Overall, the access request process is a very useful tool, especially in case where access control policies are unwritten, not clear, or entirely intuitive. However, in such cases the use of access request process is usually not a solution to a problem, it just covers up the root of the problem: lack of efficient policies. In such cases, intensive use of access certification process is likely to make the situation worse, increasing the amount of problematic role assignments, increasing maintenance effort, making it harder to introduce a systemic solution to the root problem. Moderate use of access certification process is perfectly acceptable. In fact, it is almost impossible to deploy a practical IGA solution without any access request processes. However, it has to be consumed in moderation, otherwise it will certainly get out of control.
Notes
While almost all IGA platforms implement roughly the same request-approval-fulfilment process, the details are often vastly different. There are major differences in the request user interface (a.k.a. "shopping cart"), providing varied quality of user experience. Some IGA platforms have serious implementation limitations, such as locking the entire user record for the duration of the approval process. Other system support only a single request to be active for each user at a given time. As approval process can take a long time, such limitation have severe impact on identity management and governance processes. Some systems implement the processes using internal implementation, while other use general-purpose workflow engines. The quality of integration with the workflow engine varies significantly from product to product. While the quality of user interface is usually quite obvious, other details of the access request process are hidden. As access request is often used in practice, and the quality of the entire process is essential for efficient day-to-day operation of IGA platform, it is strongly recommended investing sufficient resources to proof-of-concept of this part of the solution.
Vast majority of access request processes are dealing with role assignment requests. It is theoretically possible to implement access request processes for low-level entitlements, such as LDAP groups or operating system privileges. However, such processes tend to be very problematic. Access request processes are based on governance concepts, such as policies and ownership. It is very difficult to define such concepts for entities that reside outside of IGA platforms. Entitlements often "live" in target systems. IGA platform maintains some data about them, however, they are usually not first-class citizens of IGA platform. It would be difficult for IGA platform to determine approvers for such request. Therefore, the capabilities of IGA platforms to directly support access requests for entitlements is almost always very limited. Many IGA platforms overcome this situation by automatically maintaining roles that correspond to entitlements. For example, LDAP groups can be automatically synchronized to IGA platforms, creating application role for each LDAP group. Such application roles can then be a subject of ordinary access request process, including ability to specify policies and track ownership.
The basic idea of access request process is based on an idea that we can define what access is. This is relatively easy to do in structured access control models, such as role-based access control (RBAC). In RBAC, role is a well-specified concept that grants access, it is a natural target of access request process. However, access controls models with weaker structure are not well-suited for access request process. For example, attribute-based access control (ABAC) does not have a concept that could be used to define access. In ABAC, the access is based on many variables, it is almost impossible to specify which of them determine the access and what combinations of variables are meaningful enough to be requested. In practice, access in ABAC model is usually determined by attributes of user account. Therefore, the ABAC access request process would need to deal with values of user access attributes, values that are usually not formally specified. Such approach is very difficult to implement in a declarative form. While it is not impossible to set up and maintain an access request process for systems based on ABAC, it is vastly more difficult than an equivalent process for RBAC systems. Many practical solutions to manage ABAC-based system are re-introducing a concept of role, or a mechanisms that are functionally equivalent to roles.
Access request capability has a significant overlap with identity workflow automation capability. This is partially given by historical reasons, as traditionally the approval part of access request process was implemented by generic workflow tools.
Recent years brought a concept of approval process automation based on machine learning and artificial intelligence (AI). While AI certainly has its place in identity governance, using AI for automation of approval processes can be extremely dangerous. The "artificial intelligence" used to automate approval processes relies on machine learning mechanisms, which in turn rely on good training data or feedback. As the setup of roles, policies and organizational processes are different for each organization, the AI-based approvals cannot rely on training data produced by the vendor or other organizations. The "approval AI" needs to be trained by data and decisions made in your organization. The suggestions produced by "approval AI" will be only as good as data and decisions that you make. As the old computer science goes: garbage in, garbage out. However, how good are decisions of your approvers? There are usually several approver levels/stages to eliminate human errors. There are reviews, certification campaigns and incident investigations to further eliminate the errors and handle their consequences. In fact, there is a complete information security program, which identity governance is only a small part of. An error in approval process is often identified years after it happened. The quality of data to train the machine on is questionable, and the feedback loop is too long.
This is further amplified by almost no visibility into AI decisions. There is virtually no way how an AI can explain why it has decided the way it has decided. This is a major obstacle to accountability.
AI-assisted approvals may still be a useful tool, however, it has to be used very carefully. For example, it is perhaps a good idea to use AI to eliminate multiple levels of approval, however still keep at least one human approver in the chain. The way how the "AI" is implemented is certainly going to vary between individual vendors, the quality of the implementation is very likely to vary too. It is extremely dangerous to accept vendor’s chèque en blanc, blindly believing in the quality of implementation with no way of checking it. Access certification process is often the only real barrier between dangerous privilege accumulation and abuse. Make sure you are not making this barrier paper-thin.
AI is a very useful tool in identity governance, if used correctly. AI can be very useful for role mining, finding patterns in big data, suggesting new role definitions. AI-assisted correlation can save a lot of time, looking for a needle in a haystack, suggesting most likely candidates. However, in all such cases the AI is providing suggestions, final decisions have to be made by human. That is the right way to use AI. Do not give all the keys to your kingdom to a machine.
Rather than relaying on AI for automation of access request and access certification, the effort should be directed to a proper role and entitlement engineering. Better roles and entitlements, together with rules for their automated assignment/unassignment can dramatically reduce both the access request and access certification process, increasing transparency at the same time. Machine learning should better be employed to improve role engineering, such as use of role mining to suggest good role definitions.
Relevant MidPoint Features
Following midPoint features are relevant to this IGA capability:
| IGA Function | MidPoint Features |
|---|---|
Access request user interface |
Access request process |
Management of approval schemes |
Access request process |
Execution of approval processes |
Access request process |
Maintenance of approval accountability record |
Approval process |
Immediate fulfillment of approved requests |