To implement RBAC, you must first define all of the roles within your organization and the permissions attached to each role. A collection of users requiring the same access can be assigned to a single role. Each user can also be assigned to one or more roles and receive the collective rights associated with the assigned roles. A role policy consists of one or more rules, and each rule consists of one or more conditions and an action.
The following topics discuss how to create a role.
You create a role by selecting the appropriate conditions that qualify a user to be assigned to a role, as shown in the following page.
Figure 27-7 Role Policy Conditions
Table 27-1 describes the conditions available for a Role policy:
Table 27-1 Possible Role Conditions
Role Condition |
Description |
---|---|
Authenticating IDP |
Specifies the identity provider that authenticated the current user. To use this condition, you must have set up a trusted relationship with more than one identity provider. See Section 9.0, Configuring Trusted Providers. The most common way to use this condition is when you have a service provider that has been configured to trust two identity providers and you want to assign a role based on which identity provider authenticated the user. To configure such a policy:
For the condition to evaluate to True, the identity provider specified in the policy must be the one that the user selected for authentication. |
Authentication Contract |
Specifies the contract used to authenticate the current user. The selections in this list are defined in the Identity Server configuration ( > ). The value can be an exact string, the start, the end, or a substring.The most common way to use this condition is to select for the field and to select and the name of a contract for the field.If you select for the field, you must specify the URI of the contract for the conditions to match. For a list of these values, click > > > > . |
Authentication Method |
Specifies the method used to authenticate the current user. |
Authentication Type |
Compares a selected authentication type to the authentication types used to authenticate the current user. represents the current set of authentication types used to authenticate the user. The other selections represent specific authentication types that can be used to compare with . The condition returns True if the selected authentication type is contained in the set of authentication types for .For example, if the current user was required to satisfy the authentication types of Basic and SmartCard, then a selected authentication type of either Basic or SmartCard would match. |
Credential Profile |
Requires the user to use the specified credential for authentication. You can select LDAP (username of cn or dn and password), x509, and SAML credentials. Only values used at authentication time are available for this comparison. If you have created a custom contract that uses a credential other than the ones listed, do not use the Credential Profile as a Role condition. The value can be an exact string, the start, the end, or a substring.The default contracts assign the cn attribute to the Credential Profile. If your user store is an Active Directory server, the SAMAccountName attribute is used for the username and stored in the cn field of the LDAP Credential Profile. If you select as the type, be aware of the following requirements:
|
LDAP Group |
Specifies a group in which the authenticating user is evaluated for membership. The value, an LDAP DN, must be a fully distinguished name of a group. If the Administration Console and the Identity Server are installed on separate machines, you need to specify for the and enter the fully distinguished name of the group in the text box. For example:cn=managers,cn=users,dc=bcf2,dc=provo,dc=novell,dc=com or cn=manager,o=novell |
LDAP OU |
Specifies an OU for which the authenticating user’s DN (distinguished name) is evaluated for containment. The value, an LDAP DN, must be a fully distinguished name of an organizational unit. If the Administration Console and the Identity Server are installed on separate machines, you need to specify for the and enter the fully distinguished name of the organizational unit in the text box. For example:cn=users,dc=bcf2,dc=provo,dc=novell,dc=com or ou=users,o=novell |
LDAP Attribute |
Specifies an attribute from the user object of an authenticated user. By default the selection values include those defined by inetOrgPerson. |
Liberty User Profile |
Specifies any one of a number of data values that have been mapped to a Liberty Profile attribute. To check the mapping of attribute values, click > > > . |
Roles from Identity Provider |
Roles that are passed from an identity provider to another trusted provider. For example, a service provider requests authentication from an identity provider, which returns a role. This role might be passed to the protected resource as a condition for authorization. This condition uses the mapped attribute All Roles. All roles that are assigned to the user can be mapped to Liberty and SAML 2 attributes and assigned to a trusted identity provider. (See Section 9.8, Selecting Attributes for a Trusted Provider for information about enabling All Roles.) For an example of how to use Section 27.4, Mapping Roles between Trusted Providers. , see |
User Store |
Compares a selected user store with the user store from which the current user is authenticated. The selection represents the user store from which the user was authenticated. The other selections represent all of the configured user stores that can be used to compare with .For example, if the configured user stores are eDir1 and AD1 and the current user is authenticated from eDir1, then a selected user store of eDir1 would match and a selected user store of AD1 would not match. |
The policy action specifies the role to which the user belongs. Roles are activated at the time the role policy is evaluated. In the following page, the role of Employee is specified to be assigned to the user.
Figure 27-8 Assigning a Role
After you create roles, they are displayed as rules on the Edit Policy page, where you can review the priority, action, and a description of the role, as shown in the following page.
Figure 27-9 Rule Summary
The following instructions describe how to create two types of roles: a general Employee role and a restrictive Manager role. These roles can be used by the Access Gateway in Identity Injection policies and by the Access Gateway and the J2EE Agent in Authorization policies.
This role policy creates an Employee role. All authenticated users are assigned to this role when they log in (because it does not include conditions). This role can then be used to grant access to resources to all users in your user stores.
In the Administration Console, click Edit > >
> > >On the Policies page, click
.Select a policy type of
and specify a display name, such as Employee.Click
.On the Edit Policy page, specify a description in the
field.It is important to use this field to keep track of your roles and policies. The policy feature is powerful, and setup can be as large and complex as you want it to be, with a potentially unlimited number of conditions and choices. This description is useful to help keep track of various role and policy configurations.
Make sure the
section has no conditions, so that all users who authenticate match the condition.In the
section, click .In the Employee, then click .
box, typeIf this role needs to match the name of a role required by a Java or Web application, ensure that the case of the name matches the application’s name.
On the Edit Policy (Rule List) page, click
.On the Policies page, click
, then click .On the Role Policy page, select the Employee role, then click
On the
tab, click .This step updates the Identity Server configuration, which is required after you create a role.
To create a Manager role, continue with Manager Role.
Because the Manager role is restrictive, role policy conditions must be specified. The Manager role is assigned only to the users who meet the conditions.
Click Edit > >
> >On the Policies page, click
.Select a policy type of
and specify a display name (for this example, Manager.)Click
.In the
section, click > .In the
, select the conditions the user must meet:Liberty User Profile: Select
> > >Comparison: Select how you want the attribute values to be compared. For the Common Last Name attribute, select
> .Mode: Select
.Value: Select
and type the person’s name in the box (Smith, in this example). This sets up the condition that if the user has the name Smith, his or her role as Manager is activated at authentication.Result on Condition Error: This sets up the results that are returned if an error occurs while evaluating the condition (for example, the LDAP server goes down). This rule is set up to grant the user the role of Manager if the condition evaluates to
. If an error occurs, you do not want random users assigned the role of Manager. Therefore, for this rule, you need to select .In the
section, click .In the Manager, then click twice.
box, typeOn the Policies page, click
.Select the Manager role, then click
On the
tab, click .