Roles enable you to enforce and maintain individual accountability. Enterprise Security provides system roles, such as PortalSecOfficer and PortalGuest, and user-defined roles, which are created by the PSO. The PortalSecOfficer role is initially granted to the “pso” user, and permits unlimited access to the security system. The PortalGuest role allows Enterprise Portal users to self-register.
Roles provide individual accountability for users performing operational and administrative tasks. Their actions can be audited and attributed to them.
The PSO can define role hierarchies such that if a user is granted one role, the user is also granted roles that it inherits from. For example, the “chief_financial_officer” role might contain both the “financial_analyst” and the “salary_administrator” roles. The Chief Financial Officer can perform all tasks and see all data that can be viewed by Salary Administrators and Financial Analysts.
Enterprise Security associates access control with roles (role-based access control policy). Roles can be granted to a single user or a group of users.
A role can be granted to multiple users or groups.
A user can have multiple active roles at a time.
A role can inherit permissions from another role.
Groups can be populated with multiple users from multiple organizations.
When you create new roles, keep in mind the following functionality:
Roles can be granted to multiple users You can define a role in an organization and grant the role to multiple users by creating a group and populating the group with users to which you want to grant the same roles.
Roles can be granted to groups You can define a “group” consisting of users from different organizations who need to share the same roles. You can then grant roles at the group level.
A group can be defined at any organization level. For example, you can define a group for organization A. You can then populate the group with users from organization A and with users from the suborganizations of A.
To populate a group with users from different organizations, create the group at a common root level.
Role permissions can be inherited If the PSO wants to create a role that includes the permissions defined by another role, in addition to some new permissions, the role hierarchy eliminates duplicating the role definition and is more efficient.
For example, if you want Role1 to contain the permissions of Role2, then it is more efficient when you create Role1 to say that it inherits permissions from Role2, instead of redefining the permission set.
Also, to modify Role2 later, you need not modify Role1 to reflect the changes because it inherits its permissions from Role2 and changes to Role2 are automatically reflected in Role1.
For example:
If Role1 inherits from Role2 and Role2 inherits from Role3, Role1 implicitly inherits from Role3. This way even if you modify Role2 later to not inherit from Role3, Role1 still inherits from Role3.
A role cannot inherit from a role that either directly or indirectly inherits from it—this prevents loops in the hierarchy.
For example, if Role1 inherits from Role2, then Role2 cannot inherit from Role1. Also, if Role1 inherits from Role2 and Role2 inherits from Role3, then Role3 cannot inherit from either Role1 or Role2.
Figure 1-3: Roles inheritance restrictions
When users are granted a role, they get the privileges of all roles from which the granted role has inherited. However, users can assume only those roles that are explicitly granted to them. For example, if a user is granted Role1, which inherits from Role2, the user can assume Role1 but not Role2.
If Role1 inherits from Role2, which inherits from Role3, you get:
Figure 1-4: Roles inheritance activation
If you remove the link between Role2 and Role1, Role1 no longer contains the privileges of Role3. If you want Role1 to possess the privileges of Role3 irrespective of the definition of Role2, define Role1 to inherit from both Role2 and Role3.
For information about how to create roles and groups, see “Setting up the security system”.
