How permissions are resolved

When a user accesses a document in the Review Center, the application evaluates access through a defined sequence of steps:

1. Check for active RBAC rules

   The system checks whether the use case has active RBAC rules. If no RBAC rules are defined, the system completely restricts access to the use case for all users attempting access.

2. Match the user to rule principals

   The system compares the user’s identifier and group memberships with each rule’s principal type and principal value. The matching process is case-insensitive.

3. Evaluate attribute conditions

   The system evaluates the attribute conditions defined in the matched rules against the document’s entity data.

4. Resolve effective permissions

   The system collects permissions from all rules that satisfy attribute conditions and apply to the document’s current category.

If no rule matches at any step in the evaluation process, the system denies access.

When multiple rules match a user for the same document, the system combines permissions from all matched rules. For example:

• Rule A grants the permissions view_document and submit.
• Rule B grants the permissions view_document and archive

The system assigns the following effective permissions for the category:

• view_document
• submit
• archive

For USER type rules, the system compares the rule’s principal value directly with the user’s identifier. For group type rules, such as SECURITY_ROLE, the system retrieves the user’s group memberships and matches the rule’s principal type with the group type key and the rule’s principal value with the corresponding group values. For example, a rule with principal type SECURITY_ROLE and principal value Approver matches any user who belongs to the IFS Security Role group with the value Approver.