Defining a role hierarchy involves choosing the type of hierarchy and the roles, then implementing the hierarchy by granting roles to other roles.
For example:
grant role intern_role to specialist_role grant role doctor_role to specialist_role
This grants to “specialist” all the privileges of both “doctor” and “intern.”
To establish a hierarchy with a “super_user” role containing the sa_role and oper_role system roles, specify:
grant role sa_role to super_user grant role oper_role to super_user
If a role requires a password to be contained within
another role, the user with the role that contains the other does
not need to use the password for the contained role. In the example
above, assume that the “doctor” role usually requires
a password. The user who has the “specialist” role
does not need to enter the “doctor” password because “doctor” is
contained within “specialist.” Role passwords
are only required for the highest level role.
When creating role hierarchies:
You cannot grant a role to another role that directly contains it. This prevents duplication.
In the example above, you cannot grant “doctor” to “specialist” because “specialist” already contains “doctor.”
You can grant a role to another role that does not directly contain it.
For example, in Figure 4-1, you can grant the “intern” role to the “specialist” role, even though “specialist” already contains the “doctor” role, which contains “intern.” If you subsequently dropped “doctor” from “specialist,” then “specialist” still contains “intern.”
In Figure 4-1, “doctor” has “consultant” role permissions because “consultant” has been granted to “doctor.” The “specialist” role also has “consultant” role permissions because “specialist” contains the “doctor” role, which in turn contains the “consultant.”
However, “intern” does not have “consultant” role privileges, because “intern” does not contain the “consultant” role, either directly or indirectly.
Figure 4-1: Explicitly and implicitly granted privileges
You cannot grant a role to another role that is contained by the first role. This prevents “loops” within the hierarchy.
For example, in Figure 4-2, you cannot grant the “specialist” role to the “consultant” role; “consultant” is already contained in “specialist.”
Figure 4-2: Granting a role to a role contained by grantor
When the system security officer grants to a user a role that contains other roles, the user implicitly gets membership in all roles contained by the granted role. However, a role can be activated or deactivated directly only if the user has explicit membership in that role.
The system security officer cannot grant one role to another role that is explicitly or implicitly mutually exclusive at the membership level with the first role.
For example, in Figure 4-3, if the “intern” role is defined as mutually exclusive at the membership level with the “consultant” role, the system security officer cannot grant “intern” to the “doctor.”
Figure 4-3: Mutual exclusivity at membership
The user can activate or deactivate only directly granted roles.
For example, in the hierarchy shown in Figure 4-3, assume that you have been granted the “specialist” role. You have all the permissions of the “specialist” role, and, implicitly, because of the hierarchy, you have all the permissions of the “doctor” and “consultant” roles. However, you can activate only the “specialist” role. You cannot activate “doctor” or “consultant” because they were not directly granted to you. See “Activating and deactivating roles”.
Revoking roles from other roles is similar to granting roles to other roles. It removes a containment relationship, and the containment relationship must be a direct one.
For example:
If the system security officer revokes the “doctor” role from “specialist,” “specialist” no longer contains the “consultant” role or the “intern” role.
The system security officer cannot revoke the “intern” role from “specialist” because “intern” is not directly contained by “specialist.”
