How to Configure Chained Permissions

Chained permissions allow you to automate access management by linking permissions together. When a user is granted access to a specific application, this can automatically trigger a second, related permission, such as access to a secure zone or a license upgrade.

This approach follows the "Safety by Design" principle by ensuring that access is granted only when necessary. For example, instead of granting access to a secure zone simply because an employee works in healthcare, you grant access because they have been authorized to access the patient record system.

When the user no longer has access to any applications that require the special permission, it is automatically revoked. This ensures that users have only the access they need, for as long as they need it.

Common use cases

• Secure zone access: Granting access to an application located in a secure network zone automatically grants the user access to that zone. Access is revoked when the user no longer has any applications in that zone.

• License management: Granting a user access to a specific application (e.g., ACOS Websak) can automatically trigger an upgrade of their Microsoft 365 license from F3 to E3.

Example: Rule for granting permission

The following example shows how a derived value rule can grant a "Health and Care" permission. The rule is configured with an OR condition, meaning the user only needs to meet one of the criteria to receive the permission.

This rule grants the "Health and Care" permission (ID 5211) if either of the following conditions is met:

• Condition 1: The user has a specific combination of title and department.

  • The title is one of the following: Attorney, Director, Consultant, Manager, Mayor, City Manager, Chief, Head.

  • AND

  • Department number ice 1310.

• Condition 2: The user is granted access to a specific application.

  • The user has the app permission to SYSTEMROLE.NameId = 5711 (e.g., CosDoc).

Workflow for granting zone access

The following logic is applied when a user is granted access to a new application.

1. Check Application Location: eADM checks whether the application is located in the secure zone.

   • If Yes: The user is granted access to the secure zone. eADM checks whether access to the secure zone should also grant access to the internal zone.

     • If yes, the user is also granted access to the internal zone.

     • If not, the user is not granted access to the internal zone.

   • If No: eADM to check whether the application is in the internal zone.

2. Check Internal Zone: If the application is not in the secure zone, eADM to see if it is in the internal zone.

   • If Yes: The user is granted access to the internal zone.

   • If No: The user is not granted access to either the internal or secure zone based on this application.

Workflow for revoking zone access

The following logic is applied when a user loses access to an application.

1. Check Application Location: eADM checks whether the application the user has lost is in the secure zone.

   • If Yes: eADM whether the user still has access to other applications in the secure zone.

     • If yes, the user retains access to the secure zone.

     • If not, the user's access to the secure zone is revoked. eADM checks whether the user has any remaining applications in the internal zone. If not, access to the internal zone is also revoked.

   • If not, eADM to check whether the application was in the internal zone.

2. Check Internal Zone: eADM whether the application the user lost is in the internal zone.

   • If Yes: eADM whether the user still has access to other applications in the internal zone.

     • If yes, the user retains access to the internal zone.

     • If not, eADM a final check to determine whether the user has access to any applications in the secure zone that should grant access to the internal zone. If not, the user's access to the internal zone is revoked.