How to Use Permissions Constraints Details

The Permissions Constraints Details page provides administrators with an investigative tool to review and analyze a user’s security profile. For example, if a user reports that they cannot access a page that was previously available to them, this page provides administrators with pertinent information to help streamline the analysis. Having this information on demand allows administrators to take prompt and corrective action more efficiently.

To access the Permissions Constraints Details page for a user, go to Admin > Tools > Core Functions > Users. Select the Options drop-down for the user and select the Permissions Constraints Details option.

PERMISSION NAME PERMISSION DESCRIPTION CATEGORY
Users - View Grants the ability to search for and view summary information about users in the portal via the Admin/Users screen. This permission can be constrained by OU, User's OU, User Self and Subordinates, and Users. If multiple constraints are added, these constraints are considered OR statements. This is an administrator permission. Core Administration
User Permission and Constraint Details - View Grants ability to access the Permissions Constraints Details page for a user. This permission also grants ability to see the Permissions Constraints Details link on the Permissions page. This permission can be constrained by OU, User's OU, User, and User Self and Subordinates. This is an administrator permission. Core Administration

Permissions vs. Permissions Constraints Details

The Permissions page accessed from Admin > Tools > Core Functions > Users > Permissions displays the following information:

  • Roles, permissions, and constraints the user currently has
  • System-defined roles for which the user qualifies

System-defined roles cannot be explicitly assigned to users. They are assigned by the system if the user meets certain properties. System-defined roles are recognizable in the Roles Administration page by the missing User Assignment icon . Examples of system-defined roles:

  • Default Role for Every User in the System (most common system-defined role)
  • Manager (if the user has one or more direct subordinates)
  • Approver (if the user is an approver for one or more other users)

Key notes about system-defined roles:

  • System-defined roles and their corresponding permissions and constraints are assigned to users each time they log into the application. This means, that permissions and constraints of a system-defined role are assigned to the user’s security profile last and use the merge type “Append”.
  • The permissions and constraints are applied to the users’ security profile only while users are logged in and are removed from their security profile after they log out of the system.

Although system-defined roles are displayed on the Permissions page, their corresponding permissions and constraints are not reflected on this page. This gap in information makes it difficult for administrators to determine the actual security profiles users have when they log in to the system.

The Permissions Constraints Details page provides information about users’ existing roles and system-defined roles which more accurately represent users’ security profile when they are logged into the system. Upon login, the system uses the merge type “Append” to combine any constraints the users have on permissions from other assignable roles, using the same rules defined for appending. See Permission Constraint Calculation Use Cases.

How to Interpret Data on the Details Section

The screenshot of the Permissions page below shows that the user only has six permissions.

The screenshot of the Permissions Constraints Details page shows the same user to have significantly more permissions. The additional permissions displayed originate from the system-defined role “Default Role for Every User in the System”.

Expanding the Details link for one of the permissions confirms that it originated from the system-defined role “Default Role for Every User in the System”.

Expanding the Details link for the other permissions displays the following data:

  • The roles from which the user received the permission
  • The computed constraints for the user and the roles from which they originated

The Permissions Constraints Details page does not display information on dynamically assigned roles unless these roles have already been applied to the user’s security profile. Dynamically assigned roles will not be applied to the user until the next time they log in. Once they are applied, their security properties are persisted on the users’ records. Only then will dynamically assigned roles be visible on the Permissions Constraints Details page.

If administrators have recently defined a dynamic assignment for a role and wish to see it reflected on the Permissions Constraints Details page, they can proxy log in as the user before accessing the page.

How to Interpret Data on the History Page

While the Details section provides information on how the application interprets or computes constraints, the History page displays available raw data about a user's security profile (role, permission, constraints). As such, the data displayed on the Details may not always align with what the History page displays.

The following scenarios clarify why data on the History page are indeed accurate and not contradictory to the Details page.

Scenario 1: Corporation Constraint vs. No Constraint

The Corporation constraint and no constraint have an equal interpretation in the application. When applied to a permission, they give the user the widest access to data in the system. When combined with other constraints, they supersede them. When users have one of these two constraints defined on a permission, any attempt to append new constraints to them will be ignored by the system. The term constraint is used because, by default, most permissions added to a role are unconstrained, thus, giving users the broadest access.

Although the interpretation of Corporation constraint and No Constraint is similar, the system applies them to users differently.

  • Corporation constraint has an actual value since it is explicitly selected by administrators or by default by the application for certain permissions.
  • No constraint is indicated by the absence of any value.

In this example, on the Permissions page, the user does not have any constraints on the Action Items - EPM permission.

On the Permissions Constraints Details page, the two roles from which the user received the Action Items - EPM permission are listed in the Roles section. In this example, there are no constraints to this permission (No Constraints Found).

For the same permission, the following information is displayed on the History page:

This page tells us that this permission has two constraints associated with the role “Default Role for Every User in the System” (Restrict to User’s OU and User’s Self). Yet, based on the Details and the User Constraint Current Details sections, the user does not have any constraint listed for the Action Items - EPM permission. This is because the user received the same permission from the custom role ROLE_AUTHZ-921, which does not have any constraints. When appending constraints, the application ignores constraints if the user has the permission unconstrained from a different role.

Scenario 2: Order of Role Assignment

In this example, on the Permissions page, the user has three constraints applied on the does not have any constraints on the Bio About Preferences - Manage permission.

On the Permissions Constraints Details page, we see only one constraint applied to this permission. The user received the Corporation constraint from the custom role ROLE_AUTHZ-921 which overrides the other two constraints noted on the Permissions page (Location and user's Division constraints).

For the same permission, the following information is displayed on the History page:

There are three constraints listed under the User Constraint Current Details section. Yet, when the user logs in to the application, the user appears to have unrestricted access on their Bio About Preferences - Manage permission. To understand this outcome, examine the records on the History page by correlating the records from different sections of the page.

  1. The User Constraint Current Details section shows the user’s current constraints and when each were added. In the screenshot below, we can see that the user received the Location OU and User’s Division constraints before the Corporation constraint. Note: Constraints associated with system-defined roles are not displayed in the User Constraint Current Details section.

  1. The user’s constraint information above corresponds with the order in which the user was assigned to the roles.

  1. The details in the Security Role Assignment Details section further verify the data.

  1. The information above aligns with the role data displayed in the Permissions Constraints Details section.

Based on the data displayed on the History page, we see that the role ROLE_AUTHZ-923 has constraints before they were assigned to the user. These constraints were applied to the user when the role was added to the user’s security profile. However, the Corporation constraint from ROLE_AUTHZ-921 supersedes the Location and Division OU constraints, thereby giving this user unrestricted access on their Bio About Preferences - Manage permission. Note that the Corporation constraint from the system-defined role “Default Role for Every User in the System” is skipped since the user already had the same constraint prior to logging in to the system.

This example indicates that order matters in how constraints are saved and applied in the application.

Use Cases on Permission Constraint Calculations

Assumption

  • Merge type "Append" is used in all of the following use cases

Conditions

  • Role 1: Permission A - Constraint By Location OU
  • Role 2: Permission A - No Constraint
  • Role 3: Permission A - Corporation Constraint

Use Case 1:

  1. User receives Role 2 (without constraint)
  2. User receives Role 1 (with Location OU constraint)
  3. Result: The user has no constraints for Permission A.

Use Case 2:

  1. User receives Role 1 (with Location OU constraint)
  2. User received Role 2 (without constraint)
  3. Result: User has a Location OU constraint on Permission A. Because Role 2 has no constraint and the user already had a constraint from Role 1, the system does not remove the existing Location constraint.

Use Case 3:

  1. User receives Role 3 (with Corporation constraint)
  2. User receives Role 1 (with Location OU constraint)
  3. Result: The user has no constraints for Permission A.

Use Case 4:

  1. User receives Role 1 (with Location OU constraint)
  2. User receives Role 3 (with Corporation constraint)
  3. Result: The system appends the Corporation constraint to the user's security profile records for Permission A. Although the user has two constraints, Location and Corporation, the presence of the Corporation constraint overrides other constraints. The application determines the user has the Corporation constraint (no constraints) for Permission A.

As demonstrated by these use cases, the order of role assignment and their corresponding permissions and constraints, and the type of constraints specified in each are critical to determine the security profile for users in the application.

Due to the complexity of the processing and application of security on user profiles, the Permissions Constraints Details page and the History page provide powerful tools to enable administrators to investigate perceived security issues.