10.2.1 Understanding RBAC in Access Manager Appliance
Role-based access control (RBAC) provides a convenient way to assign a user to a particular job function or set of permissions within an enterprise, to control access. As an administrator, you probably have defined a set of roles for your needs. Your roles might include Employee, Student, Administrator, Manager, and so on. You might have web resources that you want available to all employees, or only to managers, as shown in Figure 10-1.
Figure 10-1 Traditional RBAC
Access Manager Appliance supports core RBAC functionality by providing user role mapping and the mapping of roles to resource rights and permissions. User role mapping is a primary function of a Role policy. Role mapping to resource rights is accomplished through Authorization policies. When creating a role, you assign users to the role, based on attributes of their identities. You also specify the constraints to place on the role.
Figure 10-2 RBAC Using a Policy
As shown in Figure 10-2, during user authentication, the system checks the existing Role policy to determine which roles that a user must be assigned to. After authentication, assigned roles can be used as evaluated conditions of an Authorization policy.
web server applications can also be configured to use roles for access control. For these applications you can use Access Manager Appliance to assign the users to the required roles. You can use Access Gateway Identity Injection policies to inject the assigned roles into the HTTP header that is sent to the web server.
The following examples describe ways to use roles in Access Manager Appliance:
Assigning All Authenticated Users to a Role
The system assigns roles to users when they authenticate. The following example illustrates a Role policy that creates an Employee role. All authenticated users are assigned to the role of Employee, because it does not include any conditions (see Creating an Employee Role).
Role assignment audit events can be created during authentication to Identity Server. You enabled this on the Logging page in Identity Server configuration by selecting or options.
Using a Role to Create an Authorization Policy
The simplest implementation of RBAC policies is to include roles as evaluated conditions when creating Authorization policies.
Suppose you belong to a company of 300 employees. 10 of them are managers. You can assign all employees to an Employee role and make it a condition of an Authorization policy with no restrictions. This policy permits access to web resources intended for all employees as shown in the following example:
For web resources intended only for managers, create a role called Manager. (See Creating a Manager Role). Make the Manager role as a condition of an Authorization policy. This policy denies access to any employee that does not have the Manager role. The following example illustrates this. The operand for the governing condition logic is set to If Not.
After you create Authorization policies, assign the policies to the intended resources. See Assigning an Authorization Policy to a Protected Resource.
Using Prioritized Rules in an Authorization Policy
You can create an Authorization policy for the Sales Department and set up a list of rules that evaluates whether a user has been assigned to one of the roles associated with the department, and then deny access if the user has not been assigned to any of them.
The following image illustrates this scenario:
In this example, specify a first-priority rule with a condition that allows access if a user has been assigned to the role of Sales Representative.
Add rules for users assigned to the a role of Sales Manager, Sales Vice President, and so on. You then create a lowest-priority rule that contains no conditions, and an action of Deny. This policy denies any user who has not been assigned a Sales department role. When the conditions of the rule are not met, the user is denied access by the lowest-priority rule.
For more information about using roles in Authorization policies, see Authorization Policies.