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 access is need-based. For example, instead of granting access to a secure zone because an employee works in healthcare, you grant access because they have been given access to 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 users only have the exact 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 gives 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 a permission

The following example shows how a derived value rule can grant a "Health and Care" permission. The rule is configured with an ELLER 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 are met:

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

  • Title is one of the following: Advokat, Direktør, konsulent, Konsulent, leder, Leder, Ordfører, Rådmann, Sjef, sjef.

  • OCH

  • Department number är 1310.

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

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

Workflow for granting zone access

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

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

   • If Yes: The user is granted access to the secure zone. eADM then checks if 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 no, the user is not granted access to the internal zone.

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

2. Check Internal Zone: If the application is not in the secure zone, eADM checks 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 first checks if the application the user lost is in the secure zone.

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

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

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

   • If No: eADM proceeds to check if the application was in the internal zone.

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

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

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

     • If no, eADM performs a final check to see if 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.