27.2 Creating Roles

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.

27.2.1 Selecting Conditions

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

Role 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:

  • Set the Authenticating IDP field to [Current]

  • Set the Value field to Authenticating IDP

  • Select the name of an identity provider

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 (Local > Contracts). The Comparison value can be an exact string, the start, the end, or a substring.

The most common way to use this condition is to select [Current] for the Authentication Contract field and to select Authentication Contract and the name of a contract for the Value field.

If you select Data Entry Field for the Value field, you must specify the URI of the contract for the conditions to match. For a list of these values, click Access Manager > Identity Servers > Edit > Local > Contracts.

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. [Current] 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 [Current]. The Authentication Type condition returns True if the selected authentication type is contained in the set of authentication types for [Current].

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 Comparison 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 Data Entry Field as the Value type, be aware of the following requirements:

  • If you selected LDAP User DN as the credential, you need to specify the DN of the user in the Value text box. If the comparison type is set to Contains Substring, you can match a group of users by specifying a common object that is part of their DNs, for example ou=sales.

  • If you selected X509 Public Certificate Subject as the credential, you need to specify all elements of the Subject Name of the certificate in the Value text box. Separate the elements with a comma and a space, for example, o=novell, ou=sales. If the comparison type is set to Contains Substring, you can match a group of certificates by specifying a name that is part of their Subject Name, for example ou=sales.

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 Data Entry Field for the Value 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 Data Entry Field for the Value 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 Identity Servers > Servers Edit > Liberty > LDAP Attribute Mapping.

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 Roles from Identity Provider, see Section 27.4, Mapping Roles between Trusted Providers.

User Store

Compares a selected user store with the user store from which the current user is authenticated. The [Current] 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 [Current].

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.

27.2.2 Selecting an Action

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

Activate role

27.2.3 Reviewing the Rules

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

Rule list

27.2.4 Example Role Policies

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.

Employee Role

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.

  1. In the Administration Console, click Access Manager > Identity Servers > Servers > Edit > Roles > Manage Policies.

  2. On the Policies page, click New.

    Employee role policy type
  3. Select a policy type of Identity Server: Roles and specify a display name, such as Employee.

  4. Click OK.

  5. On the Edit Policy page, specify a description in the Description 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.

  6. Make sure the Condition Group 1 section has no conditions, so that all users who authenticate match the condition.

    Policy conditions and actions
  7. In the Actions section, click Activate Role.

  8. In the Activate Role box, type Employee, then click OK.

    If 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.

  9. On the Edit Policy (Rule List) page, click OK.

  10. On the Policies page, click Apply Changes, then click Close.

    Enabling an Employee role
  11. On the Role Policy page, select the Employee role, then click Enable.

  12. On the Servers tab, click Update Servers.

    This step updates the Identity Server configuration, which is required after you create a role.

  13. To create a Manager role, continue with Manager Role.

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.

  1. Click Identity Servers > Servers > Edit > Roles > Manage Policies.

  2. On the Policies page, click New.

    New manager role
  3. Select a policy type of Identity Server: Roles and specify a display name (for this example, Manager.)

  4. Click OK.

  5. In the Conditions section, click New > Liberty User Profile.

    Selecting policy conditions
  6. In the Condition Group 1, select the conditions the user must meet:

    Liberty User Profile: Select Entire Personal Identity > Entire Common Name > Common Analyzed Name > Common Last Name.

    Comparison: Select how you want the attribute values to be compared. For the Common Last Name attribute, select String > Equals.

    Mode: Select Case Insensitive.

    Value: Select Data Entry Field 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 True. If an error occurs, you do not want random users assigned the role of Manager. Therefore, for this rule, you need to select False.

  7. In the Actions section, click Activate Role.

    Adding a Manager role
  8. In the Activate Role box, type Manager, then click OK twice.

  9. On the Policies page, click Apply Changes.

    Enabling a Manager role
  10. Select the Manager role, then click Enable

  11. On the Servers tab, click Update Servers.