Authors – Ramakrishna J Gorthi (rjgorthi@in.ibm.com) & Vaibhav V Gadge (vaigadge@in.ibm.com)

Identity Governance and Intelligence (IGI) allows enterprises to provision, audit and report user access and his activities through life cycle, compliance and analytics capabilities. While one of the core functions of IGI revolves around providing a common platform for requesting accesses for any given application in the enterprise, there are ways to enforce better governance by configuring the way the system responses to risky access requests.

When the user is requesting for himself OR others, we always show the current Risk Posture of that beneficiary in the form of a coloured flag (As shown in Figure 1):

1. Green Flag – Low Risk user.
2. Yellow Flag – Medium Risk user.
3. Red Flag – High Risk user.

The Risk Posture of the user changes based on the assignments that you remove from the user OR for that matter pick new entitlements from the access catalog. Basically, Risk Posture of a User is a function of the “Current Set of Entitlements”, “Entitlements removed from a user”, “New Entitlements added to the Shopping Cart”.

You could configure the system behaviour corresponding to the Risk Posture change. Say, if the risk posture of the user was to change owing to a specific entitlement addition to the shopping cart, you could say block that access request from submission. Likewise, you can configure a few other responses that the system could take. You can configure the way the system responds to Risk Posture Change, as shown in Figure 2.

Figure 2. Risk Response Configuration

So, there are three different responses you can configure:

1. Alert the user with a message and block the request.
2. Alert the user with a message and continue with the request.
3. Change the colour of the Risk Flag, as appropriate, and keep it blinking.

You could configure either of these responses for any given risk posture update:

1. High Risk Response – A response you would set if the Risk Posture for the user jumped up to High.
2. Medium Risk Response – A response you would set if the Risk Posture for the user jumped up to Medium.
3. Low Risk Response – A response you would set if the Risk Posture for the user jumped up from No Risk to Low Risk.

You could match up the right Risk Level to Response, to get the desired compliance in the system. If I go ahead with the configuration as shown in Figure 2, here’s how the system behaves, if I were to request for a High Risk Access:

Figure 3. System Response to Risky Access Requests

In this specific case, user won’t be able to complete his request, since the system is configured in a way that the request is blocked.