Example Role Removal

The role removal feature requires a configuration in the Airlock Gateway and a corresponding configuration in Airlock IAM.

Airlock IAM:

In this example, Airlock IAM is configured with three target applications with their own authentication flows and tags as follows:

• Each target application has its own flow and in the respective identity propagation, the respective role is derived from the tags and added to the Gateway.
• The tags needed to get the roles are shared between App 1 and App 2.
• Target App 3 and the corresponding role are only used for illustration purposes to show an unaffected app/role.

Airlock Gateway:

Airlock Gateway is configured to drop roles if the Anomaly Shield detects anomalous behavior on a particular mapping.

• Anomalous behavior on App 1 will remove both role1 and role2.
• Anomalous behavior on App 2 will remove both role1 and role2.
• Anomalous behavior on App 3 will remove role3.

1. For every request, Airlock Gateway provides Airlock IAM with the AL_ENV_ROLES and AL_ENV_REMOVED_ROLES environment cookies. The example starts after the user successfully authenticated for all three roles: role1, role2, role3.
2. An event in the Gateway forces the Gateway to drop role1 and role2.
3. Since the user tries to continue to work with App 1, the Gateway redirects the user to Airlock IAM to re-acquire the necessary authorization. role1 and role2 are now part of the AL_ENV_REMOVED_ROLES environment cookie.
4. Airlock IAM starts an authentication flow. During the start of the flow, the AL_ENV_REMOVED_ROLES environment cookie is processed. The removal of both role1 and role2 instruct IAM to remove the tag strong.
   Then IAM continues to process the authentication flow. Since the tag strong is missing, the authentication flow will ask the user to re-authenticate with a second factor.
5. The authentication flow completes successfully and IAM instructs the Gateway to re-add role1.
   Note: role2 is not yet added. Should the user try to access App 2, the Gateway would start another authentication flow since role2 is still missing. This authentication flow would run without user interaction since the tag strong is already in the session.
6. IAM stores the information that it already processed the removal of role2 to ensure that this process is only done once.
7. All future requests from the Gateway now contain the update environment cookies and only role2 remains in the AL_ENV_REMOVED_ROLES environment cookie.

Testing the role removal feature is not straightforward, since it is difficult to force the Gateway to declare a session anomalous.

• The following ideas may help when preparing a test setup:
• If you create a trigger rule in the Anomaly Shield, where all indicators are gray, this rule will allow a limited number of requests without evaluation at the start of a session. The first request that evaluates, will trigger the pattern and be reported as anomalous.
• The Multiple Countries indicator can be triggered easily by manipulating the client's IP address. See Client IP behind proxy for more details.