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
Figure 10-3: Creating a role hierarchy
In Figure 10-3, the “specialist” role contains the “doctor” and “intern” roles. This means that “specialist” has 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 that requires a password is contained within another role, the user with the role that contains the other does not need to use the password for the contained role. For example, in Figure 10-3, say 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.
For example, in Figure 10-3, 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 10-4, 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” would still contains “intern.”
In Figure 10-4, “doctor” has “consultant” role permissions because “consultant” has been granted “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.
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 10-5, you cannot grant the “specialist” role to the “consultant” role; “consultant” is already contained in “specialist”.
When the System Security Officer grants 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 only be activated or deactivated directly 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 10-6, 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.”
The user can activate or deactivate only directly granted roles.
For example, in the hierarchy shown in Figure 10-6, 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. For information, 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, as shown in Figure 10-7:
For example, in Figure 10-7:
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.”