6.2 Role Policies

This section describes the following topics for the Identity Server roles.

6.2.1 Understanding RBAC in Access Manager

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, in order 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 6-1.

Figure 6-1 Traditional RBAC

Access Manager 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 6-2 RBAC Using a Policy

As shown in Figure 6-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.

Java applications and Web server applications can also be configured to use roles for access control. For these applications you can use Access Manager to assign the users to the required roles. You can use the 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:

Assigning All Authenticated Users to a Role

The system assigns users to roles 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).

Figure 6-3 Employee Role Policy

Role assignment audit events can be created during authentication to the Identity Server. You enabled this on the Logging page in the Identity Server configuration when you enable the Login Provided or Login Consumed options.

Using a Role to Create an Authentication 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, and ten 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. Such a policy would permit access to Web resources intended for all employees, as shown in the following example:

Figure 6-4 Employee Authorization Policy

For more sensitive Web resources intended only for managers, you might create a role called Manager. (See Creating a Manager Role). The Manager role might be a condition of an Authorization policy that denies access to any employee that has not been assigned to the Manager role when the user authenticated. The following example illustrates this. Notice that the operand for the governing condition logic is set to If Not.

Figure 6-5 Manager Authorization Policy

After you have created the Authorization policies, you need to assign the policies to the resources they were designed to protect.

See Assigning an Authorization Policy to a Protected Resource.

Using Prioritized Rules in an Authorization Policy

In another policy example, you might create an Authorization policy for the Sales Department and set up a list of rules that evaluate 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:

Figure 6-6 Authorization Policy with Multiple Rules

In this example, you specify a first-priority rule with a condition that allows access if a user has been assigned to the role of Sales Representative. You 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 users do not meet the conditions of the rules, the user is denied access by the lowest-priority rule.

For more information about using roles in Authorization policies, see Section 6.3, Authorization Policies.

6.2.2 Enabling Role-Based Access Control

Role-based access control is used to provide a convenient way to assign a user to a particular job function or set of permissions within an enterprise, in order to control access. In Access Manager, you assign users to roles, based on attributes of their identity, and then associate policies to the role.

To assign a role to users at authentication, you must enable it for the Identity Server configuration.

In the Administration Console, click Devices > Identity Servers > Servers > Edit > Roles.
Click the role policy’s check box, then click Enable.
To disable the role policy, click the role policy’s check box, then click Disable.
To create a new role, click Manage Policies.
After enabling or disabling role policies, update the Identity Server configuration on the Servers tab.

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

In the Administration Console, click Policies > Policies.
Select the policy container, then click New.
Specify a name for the policy, then select Identity Server: Roles for the type of policy.
Fill in the following fields:

Description: (Optional) Describe the purpose of this rule. If your role policy contains multiple rules, use the description to identify the purpose of each rule.

Priority: Specify the order in which a rule is applied in the policy, when the policy has multiple rules. The highest priority is 1 and 10 is the lowest.
To create a condition for a policy rule, click New in the Condition Group 1 section, then select one of the following:
- 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. For configuration information, see Authenticating IDP Condition.
- Authentication Contract: Specifies the contract used to authenticate the current user. The selections in this list are defined in the Identity Server configuration. For configuration information, see Authentication Contract Condition.
- Authentication Method: Specifies the method used to authenticate the current user. For configuration information, see Authentication Method Condition.
- Authentication Type: Compares a selected authentication type to the authentication types used to authenticate the current user. For configuration information, see Authentication Type Condition.
- Credential Profile: Requires the user to use the specified credential for authentication. Only values used at authentication time are available for this comparison. For configuration information, see Credential Profile Condition.
- LDAP Group: Specifies a group in which the authenticating user is evaluated for membership. For configuration information, see LDAP Group Condition.
- LDAP OU: Specifies an OU against which the authenticating user's container is evaluated for containment. For configuration information, see LDAP OU Condition.
- LDAP Attribute: Specifies an attribute from the user object of an authenticated user. By default, the selection values include those defined for the InetOrgPerson class. For configuration information, see LDAP Attribute Condition.
- Liberty User Profile: Specifies any one of a number of data values that have been mapped to a Liberty Profile attribute. For configuration information, see Liberty User Profile Condition.
- Roles from Identity Provider: Specifies a role that has been assigned to the user by an identity provider. For configuration information, see Roles from Identity Provider Condition.
- Risk Score:
- User Store: Compares a selected user store to the user store where the current user is authenticated. For configuration information, see User Store Condition.
- Condition Extension: (Conditional) If you have loaded and configured a role condition extension, this option specifies a condition that is evaluated by an outside source. See the documentation that came with the extension for information about what is evaluated.
- Data Extension: (Conditional) If you have loaded and configured a role data extension, this option specifies the value that the extension retrieves. You can then select to compare this value with an LDAP attribute, a Liberty User Profile attribute, a Data Entry Field, or another Data Extension. For more information, see the documentation that came with the extension.
NOTE:To improve the policy's performance, configure the LDAP Attributes, Credential Profile, and Liberty User Profile attributes to be sent with authentication. For more information, seeConfiguring the Attributes Sent with Authentication.
(Conditional) To add multiple conditions, repeat Step 5.

For more information about using multiple conditions in a rule, see Using Multiple Conditions.
In the Actions section, select one of the following:
- Activate Role: Select this option to specify a name for the role. If you are creating a role that needs to be injected into an HTTP header, use the capitalization format that the Web server expects.
- Activate Selected Role: Select this option to obtain the role value from an external source.
For more information about specifying a role or roles to activate, see Selecting an Action.
Click OK twice.
Click Apply Changes.
To enable the role for an Identity Server configuration, see Section 6.2.7, Enabling and Disabling Role Policies.

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

Figure 6-7 Role Policy Conditions

The following sections describe the conditions available for a Role policy:

Authenticating IDP Condition

The Authenticating IDP condition allows you to assign a role based on 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 3.9.3, Managing 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.

Comparison: Specify how the contract is compared to the data in the Value field. Select either a string comparison or a regular expression:

Comparison: String: Specifies that you want the values compared as strings and how you want the string values compared. Select one of the following:
- Equals: Indicates that the values must match, letter for letter.
- Starts with: Indicates that the Authenticating IDP value must begin with the letters specified in the Value field.
- Ends with: Indicates that the Authenticating IDP value must end with the letters specified in the Value field.
- Contains Substring: Indicates that the Authenticating IDP value must contain the letters, in the same sequence, as specified in the Value field.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: Select the mode appropriate for the comparison type:

Comparison: String: Specify whether case is important by selecting Case Sensitive or Case Insensitive.
Comparison: Regular Expression: Matches: Select one or more of the following:
- Canonical Equivalence
- Case Insensitive
- Comments
- Dot All
- Multi-Line
- Unicode
- Unix Lines
For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Specify the value you want to compare with the Authenticating IDP value. If you select a static value for the Authenticating IDP value, select Authenticating IDP and Current. If you select Current for the Authenticating IDP value, select Authenticating IDP, then select the name of an identity provider.

Other value types are possible if you selected Current for the Authenticating IDP value. Your policy requirements determine whether they are useful.

Result on Condition Error: Specify what the condition returns when the comparison of the two values returns an error rather than the results of the comparison. Select either False or True. If you do not want the action applied when an error occurs, select False. If you want the action applied when an error occurs, select True.

Authentication Contract Condition

The Authentication Contract allows you to assign a role based on the contract the user used for authentication. The Identity Server has the following default contracts:

Name	URI
Name/Password - Basic	basic/name/password/uri
Name/Password - Form	name/password/uri
Secure Name/Password - Basic	secure/basic/name/password/uri
Secure Name/Password - Form	secure/name/password/uri

To configure other contracts for your system, click Devices > Identity Servers > Edit > Local > Contracts.

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.

To specify an Authentication Contract condition, fill in the following fields:

Authentication Contract: To compare the contract that the user used with a static value, select Current. To compare a static value with what the user used, select a contract from the list.

If you have created more than one Identity Server configuration, select the configuration, then select the contract. The name of the contract is displayed. When you select this name, the configurations that contain a definition for this contract are highlighted.

For example, the following policy has selected Name/Password - Basic as the contract.

Two Identity Server configurations have been defined (idp-43.amlab.net and idp-51.amlab.net). Both configurations are highlighted because Name/Password - Basic is a contract that is automatically defined for all Identity Server configurations.

If the contract you are selecting for a condition is a contract with ORed credentials, you need to use multiple conditions to set up a rule. See Creating a Rule for a Contract with ORed Credentials.

Comparison: Specify how the contract is compared to the data in the Value field. Select either a string comparison or a regular expression:

Comparison: String: Specifies that you want the values compared as strings and how you want the string values compared. Select one of the following:
- Equals: Indicates that the values must match, letter for letter.
- Starts with: Indicates that the Authentication Contract value must begin with the letters specified in the Value field.
- Ends with: Indicates that the Authentication Contract value must end with the letters specified in the Value field.
- Contains Substring: Indicates that the Authentication Contract value must contain the letters, in the same sequence, as specified in the Value field.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: Select the mode appropriate for the comparison type:

Comparison: String: Specify whether case is important by selecting Case Sensitive or Case Insensitive.
Comparison: Regular Expression: Matches: Select one or more of the following:
- Canonical Equivalence
- Case Insensitive
- Comments
- Dot All
- Multi-Line
- Unicode
- Unix Lines
For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Specify the value you want to compare with the Authentication Contract value. If you select a static value for the Authentication Contract value, select Authentication Contract and Current. If you select Current for the Authentication Contract value, select Authentication Contract, then select the name of a contract.

Other value types are possible if you selected Current for the Authentication Contract value. For example:

You can select Data Entry Field. The value specified in the text box must be the URI of the contract for the conditions to match. For a list of these values, click Devices > Identity Servers > Edit > Local > Contracts.
If you have defined a Liberty User Profile attribute for URI of the authentication contract, you can select Liberty User Profile, then select the attribute.
If you have defined an LDAP attribute for URI of the authentication contract, you can select LDAP Attribute, then select the attribute.

Authentication Method Condition

The Authentication Method allows you to assign a role based on the method the user used for authentication.

Authentication Method: To compare the method that the user used with a static value, select Current. To compare a static value with what the user used, select a method from the list.

If you have created more than one Identity Server configuration, select the configuration, then select the method. The name of the method is displayed. When you select this name, the configurations that contain a definition for this method are highlighted.

Comparison: Specify how the method is compared to the data in the Value field. Select either a string comparison or a regular expression:

Comparison: String: Specifies that you want the values compared as strings and how you want the string values compared. Select one of the following:
- Equals: Indicates that the values must match, letter for letter.
- Starts with: Indicates that the Authentication Method value must begin with the letters specified in the Value field.
- Ends with: Indicates that the Authentication Method value must end with the letters specified in the Value field.
- Contains Substring: Indicates that the Authentication Method value must contain the letters, in the same sequence, as specified in the Value field.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: Select the mode appropriate for the comparison type:

Comparison: String: Specify whether case is important by selecting Case Sensitive or Case Insensitive.
Comparison: Regular Expression: Matches: Select one or more of the following:
- Canonical Equivalence
- Case Insensitive
- Comments
- Dot All
- Multi-Line
- Unicode
- Unix Lines
For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Specify the value you want to compare with the Authentication Method value. If you select a static value for the Authentication Method value, select Authentication Method and Current. If you select Current for the Authentication Method value, select Authentication Method, then select the name of a method.

Other value types are possible if you selected Current for the Authentication Method value. Your policy requirements determine whether they are useful.

Authentication Type Condition

The Authentication Type condition allows you to assign a role based on the authentication types used to authenticate the current user. The [Current] selection 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.

Authentication Type: To compare the type that the user used with a static value, select Current. To compare a static value with what the user used, select a type from the list.

Comparison: Specify how the type is compared to the data in the Value field. Select either a string comparison or a regular expression:

Comparison: String: Specifies that you want the values compared as strings and how you want the string values compared. Select one of the following:
- Equals: Indicates that the values must match, letter for letter.
- Starts with: Indicates that the Authentication Type value must begin with the letters specified in the Value field.
- Ends with: Indicates that the Authentication Type value must end with the letters specified in the Value field.
- Contains Substring: Indicates that the Authentication Type value must contain the letters, in the same sequence, as specified in the Value field.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: Select the mode appropriate for the comparison type:

Comparison: String: Specify whether case is important by selecting Case Sensitive or Case Insensitive.
Comparison: Regular Expression: Matches: Select one or more of the following:
- Canonical Equivalence
- Case Insensitive
- Comments
- Dot All
- Multi-Line
- Unicode
- Unix Lines
For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Specify the value you want to compare with the Authentication Type value. If you select a static value for the Authentication Type value, select Authentication Type and Current. If you select Current for the Authentication Type value, select Authentication Type, then select a type.

Other value types are possible if you selected Current for the Authentication Type value. Your policy requirements determine whether they are useful.

Credential Profile Condition

The Credential Profile condition allows you to assign a role based on the credentials the user entered when authenticating to the system. Only values used at authentication time are available for this comparison.

To set up the matching for this condition, fill in the following fields:

Credential Profile: Specify the type of credential your users are using for authentication. If you have created a custom contract that uses a credential other than the ones listed below, do not use the Credential Profile as a Role condition.

LDAP Credentials: If you prompt the user for a username, select this option, then select LDAP User Name (the cn of the user) or LDAP User DN (the fully distinguished name of the user), or LDAP Password.

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.
X509 Credentials: If you prompt the user for a certificate, select this option, then select one of the following:
- X509 Public Certificate Subject: Retrieves the subject field from the certificate, which can match the DN of the user, depending upon who issued the certificate.
- X509 Public Certificate Issuer: Retrieves the issuer field from the certificate, which is the name of the certificate authority (CA) that issued the certificate.
- X509 Public Certificate: Retrieves the entire certificate, Base64 encoded.
- X509 Serial Number: Retrieves the serial number of the certificate.
SAML Credential: If your users authenticate with a SAML assertion, select this option.

Comparison: Select one of the following types:

Comparison: String: Specifies that you want the values compared as strings and indicates how you want the string values compared. Select one of the following:
- Equals: Indicates that the values must match, letter for letter.
- Starts with: Indicates that the Credential Profile value must begin with the letters specified in the Value field.
- Ends with: Indicates that the Credential Profile value must end with the letters specified in the Value field.
- Contains Substring: Indicates that the Credential Profile value must contain the letters, in the same sequence, as specified in the Value field.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: Select the mode appropriate for the comparison type:

Comparison: String: Specify whether case is important by selecting Case Sensitive or Case Insensitive.
Comparison: Regular Expression: Matches: Select one or more of the following:
- Canonical Equivalence
- Case Insensitive
- Comments
- Dot All
- Multi-Line
- Unicode
- Unix Lines
For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Specify the second value for the comparison. Select one of the following data types:

LDAP Attribute: If you have an LDAP attribute that corresponds to the Credential Profile you have specified, select this option and the attribute.
Liberty User Profile: If you have a Liberty User Profile attribute that corresponds to the Credential Profile you have specified, select this option and the attribute.
Data Entry Field: Specify the string you want matched. 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 the Subject Name, for example ou=sales.

Other values are possible. Your policy requirements determine whether they are useful.

LDAP Group Condition

The LDAP Group condition allows you to assign a role based on whether the authenticating user is a member of a group. The value, an LDAP DN, must be a fully distinguished name of a group.

LDAP Group: Select [Current].

Comparison: Specify how you want the values compared. Select one of the following:

LDAP Group: Is Member of: Specifies that you want the condition to determine whether the user is member of a specified group.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: If you selected Regular Expression: Matches as the comparison type, select one or more of the following:

Canonical Equivalence
Case Insensitive
Comments
Dot All
Multi-Line
Unicode
Unix Lines

For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Specify the second value for the comparison. If you select LDAP Group > Name of Identity Server Configuration > User Store Name, you can browse to the name of the LDAP group.

If you have more than 250 groups in your tree, you are prompted to enter an LDAP query string. In the text box, you need to add only the <strFilter> value for the query. For example:

<strFilter> Value	Description
admin*	Returns all groups that begin with admin, such as adminPR, adminBG, and adminWTH.
*test	Returns all groups that end with test, such as doctest, softtest, and securtest.
low	Returns all groups that have “low” in the name, such as low, yellow, and clowns.

For more information about the <strFilter> parameter, see RFC 2254 “LDAP Search Filter.”

If you select Data Entry Field as the value, you can specify the DN of the group in the text field. For example:

cn=managers,cn=users,dc=bcf2,dc=provo,dc=novell,dc=com

cn=manager,o=novell

Other values are possible. Your policy requirements determine whether they are useful.

LDAP OU Condition

The LDAP OU condition allows you to assign a role based on a comparison of the DN of an OU against the DN of the authenticated user. If the user’s DN contains the OU, the condition matches.

LDAP OU: Select [Current].

Comparison: Specify how you want the values compared. Select one of the following:

Contains: Specifies that you want the condition to determine whether the user is contained by a specified organizational unit.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: Select the mode appropriate for the comparison type.

Contains: Select whether the user must be contained in the specified OU (One Level) or whether the user can be contained in the specified OU or a child container (Subtree).
Comparison: Regular Expression: Matches: Select one or more of the following:
- Canonical Equivalence
- Case Insensitive
- Comments
- Dot All
- Multi-Line
- Unicode
- Unix Lines
For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Specify the second value for the comparison. If you select LDAP OU > Name of Identity Server Configuration > User Store Name, you can browse to the name of the OU.

If you have more than 250 OUs defined in your tree, you are prompted to enter an LDAP query string. In the text box, you need to add only the <strFilter> value for the query. For example:

<strFilter> Value	Description
admin*	Returns all OUs that begin with admin, such as adminPR, adminBG, and adminWTH.
*test	Returns all OUs that end with test, such as doctest, softtest, and securtest.
low	Returns all OUs that have “low” in the name, such as low, yellow, and clowns.

For more information about the <strFilter> parameter, see RFC 2254 “LDAP Search Filter.”

If you select Data Entry Field, you can specify the DN of the OU in the text field. For example:

cn=users,dc=bcf2,dc=provo,dc=novell,dc=com

ou=users,o=novell

If you have defined a Liberty User Profile or an LDAP attribute for the OU you want to match, select this option, then select your attribute.

LDAP Attribute Condition

The LDAP Attribute condition allows you to assign a role based on a value in an LDAP attribute defined for the inetOrgPerson class or any other LDAP attribute you have added. You can have the user’s attribute value retrieved from your LDAP directory and compared to a value of the following type:

Roles from an identity provider
Authenticating IDP or user store
Authentication contract, method, or type
Credential profile
LDAP attribute, OU, or group
Liberty User Profile attribute
Static value in a data entry field

To set up the matching for this condition, fill in the following fields:

LDAP Attribute: Specify the LDAP attribute you want to use in the comparison. Select from the listed LDAP attributes. To add an attribute that isn’t in the list, click New LDAP Attribute, then specify the name of the attribute.

Comparison: Specify how you want the values compared. All data types are available. Select one that matches the value type of your attribute.

Mode: Select the mode, if available, that matches the comparison type. For example, if you select to compare the values as strings, you can select either a Case Sensitive mode or a Case Insensitive mode.

Value: Specify the second value for the comparison. All data types are available. For example, you can select to compare the value of one LDAP attribute to the value of another LDAP attribute. Only you can determine if such a comparison is meaningful.

Liberty User Profile Condition

The Liberty User Profile condition allows you to assign a role based on a value in a Liberty User Profile attribute. The Liberty attributes must be enabled before you can use them in policies (click Identity Servers > Edit > Liberty > Web Service Provider, then enable one or more of the following: Employee Profile or Personal Profile).

These attributes can be mapped to LDAP attributes (click Identity Servers > Edit > Liberty > LDAP Attribute Mapping). When mapped, the actual value comes from your user store. If you are using multiple user stores with different LDAP schemas, mapping similar attributes to the same Liberty User Profile attribute allows you to create one policy with the Liberty User Profile attribute rather than multiple policies for each LDAP attribute.

The selected attribute is compared to a value of the following type:

Roles from an identity provider
Authenticating IDP or user store
Authentication contract, method, or type
Credential profile
LDAP attribute, OU, or group
Liberty User Profile attribute
Static value in a data entry field

To set up the matching for this condition, fill in the following fields:

Liberty User Profile: Select the Liberty User Profile attribute. These attributes are organized into three main groups: Custom Profile, Corporate Employment Identity, and Entire Personal Identity. By default, the Common Last Name attribute for Liberty User Profile is mapped to the sn attribute for LDAP. To select this attribute for comparison, click Entire Personal Identity > Entire Common Name > Common Analyzed Name > Common Last Name.

Comparison: Select the comparison type that matches the data type of the selected attribute and the value.

Mode: Select the mode, if available, that matches the data type. For example, if you select to compare the values as strings, you can select either a Case Sensitive mode or a Case Insensitive mode.

Value: Select one of the values that is available from the current request or select Data Entry Field to enter a static value. The static value that you can enter depends on the comparison type you selected.

Roles from Identity Provider Condition

The Roles from Identity Provider condition allows you to assign a role based on a role assigned by another identity provider (Liberty, SAML 2.0, WS Federation). You configure the condition to match the role sent by the identity provider, then set the action to assign a new role.

This condition uses the mapped attribute All Roles. All roles that are assigned to the user can be mapped to attributes and assigned to a trusted identity provider. For information about enabling All Roles, see Section 3.9.6, Selecting Attributes for a Trusted Provider.

For an example of how to use Roles from Identity Provider to create a Role policy, see Section 6.2.6, Mapping Roles between Trusted Providers. For an example that explains all the configuration procedures required for sharing roles, see Sharing Roles.

To configure a Roles from Identity Provider condition, fill in the following fields:

Roles from Identity Provider: If you have configured your system for multiple identity providers, select the identity provider. If you have only one, it is selected.

Comparison: Select one of the following types:

Comparison: String: Specifies that you want the values compared as strings, and how you want the string values compared. Select one of the following:
- Equals: Indicates that the values must match, letter for letter.
- Starts with: Indicates that the Roles from Identity Provider value must begin with the letters specified in the Value field.
- Ends with: Indicates that the Roles from Identity Provider value must end with the letters specified in the Value field.
- Contains Substring: Indicates that the Roles from Identity Provider value must contain the letters, in the same sequence, as specified in the Value field.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Mode: Select the mode appropriate for the comparison type:

Comparison: String: Specify whether case is important by selecting Case Sensitive or Case Insensitive.
Comparison: Regular Expression: Matches: Select one or more of the following:
- Canonical Equivalence
- Case Insensitive
- Comments
- Dot All
- Multi-Line
- Unicode
- Unix Lines
For regular expression syntax information, see the Javadoc for java.util.regex.Pattern.

Value: Select Data Entry Field, then specify the name of an identity provider role. Other value types are possible. Your policy requirements determine whether they are useful

User Store Condition

The User Store condition allows you to assign a role based on the user store that was used to authenticate the current user. 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.

User Store: To compare the user store that the user used for authentication with a static value, select Current. To compare a static value with what the user used, select a user store from the list.

If you have created more than one Identity Server configuration, select the configuration, then select the user store. The name of the user store is displayed.

Comparison: Specify how the user store is compared to the data in the Value field. Select either a string comparison or a regular expression:

Comparison: String: Specifies that you want the values compared as strings and how you want the string values compared. Select one of the following:
- Equals: Indicates that the values must match, letter for letter.
- Starts with: Indicates that the User Store value must begin with the letters specified in the Value field.
- Ends with: Indicates that the User Store value must end with the letters specified in the Value field.
- Contains Substring: Indicates that the User Store value must contain the letters, in the same sequence, as specified in the Value field.
Comparison: Regular Expression: Matches: Specifies that you want the values compared as regular expressions.

Value: Specify the value you want to compare with the User Store value. If you select a static value for the User Store value, select User Store and Current. If you select Current for the User Store value, select User Store, then select the name of a user store.

If you have created more than one Identity Server configuration, select the configuration, then select the user store. The name of the user store is displayed.

Other value types are possible if you selected Current for the User Store value. Your policy requirements determine whether they are useful.

Condition Extension

If you have loaded and configured a role condition extension, this option specifies a condition that is evaluated by an outside source. See the documentation that came with the extension for information about what is evaluated.

Data Extension

If you have loaded and configured a role data extension, this option specifies the value that the extension retrieves. You can then select to compare this value with an LDAP attribute, a Liberty User Profile attribute, a Data Entry Field, or another Data Extension. For more information, see the documentation that came with the extension.

Using Multiple Conditions

The Condition structure field controls how conditions within a condition group interact with each other and how condition groups interact with each other. Select one of the following:

The following sections explain how to configure the condition groups and conditions to interact with each other:

AND Conditions, OR groups

If the conditions are ANDed, the user must meet all the conditions in a condition group to match the profile. If the condition groups are ORed, the user must meet all of the conditions of one group to match the profile. This option allows you to set up two or more profiles into which a user could fit and be considered a match. For example, suppose you create the following Permit rule.

The first condition group contains the following conditions:

The user’s department must be Engineering.
The request must come on a weekday.

The second condition group contains the following conditions:

The user’s department must be Information Services and Technology (IS&T).
The request must come on a weekend.

With this rule, the engineers who match the first condition group have access to the resource during the week, and the IS&T users who match the second condition group have access to the resource on the weekend.

OR Conditions, AND groups

If the conditions are ORed, the user must meet at least one condition in the condition group to match the profile. If the conditions groups are ANDed, the user must meet at least one condition in each condition group to match the profile. For example, suppose you created the following Permit rule:

The first condition group contains the following conditions:

The user’s department is Engineering.
The user’s department is Sales.

The second condition group contains the following conditions:

The user has been assigned the Party Planning role.
The user has been assigned the Vice President role.

With this rule, the Vice Presidents of both the Engineering and Sales departments can access the resource, and the users from the Engineering and Sales department who have been assigned to the Party Planning role can access the resource.

Using the Not Options

At the top of each condition group, there is an option that allows you to control whether the user must match the conditions to match the profile or whether the user matches the profile if the user doesn’t match any of the conditions. Depending upon your selection for the Condition structure, you can select from the following:

If/If Not
Or/Or Not
And/And Not

Conditions also have similar Not options, so that a user can match a condition by not matching the specified value.

Adding Multiple Conditions

To add another condition to a condition group, click New, then select a condition. To copy an existing condition, click the Copy Condition icon . New conditions are always added to the end of the condition group. Use the Move buttons to order the conditions in the condition group.

Adding New Condition Groups

To add another condition group to the rule, click Append New Group. To copy the existing condition group, click the Copy Group icon . New condition groups are always added to the end to the Conditions section. Use the Move buttons to order the condition groups.

Disabling Conditions and Condition Groups

Condition groups and conditions within them can be disabled by clicking the Enabled check mark , which changes the icon to the Disabled icon .

You usually disable a condition or condition group when testing a new rule, and if you decide the condition or condition group is not needed, you can then use the Delete button to delete the condition or condition group from the rule. Use the Move buttons by the Delete button to move a condition up or down within its group. Condition groups also have Move buttons.

Selecting an Action

The policy action specifies the role to which the user is assigned. Roles are activated at the time the role policy is evaluated. Select one of the following actions:

Activate Role

Select Activate Role when you want to specify a name for the role. If you are creating a role that needs to injected into an HTTP header, use the same capitalization format as the Web server expects. For example, if the Web server expects an Employee role with an initial capital, name your role Employee.

Figure 6-8 show how to assign the role of Employee to a policy.

Figure 6-8 Assigning a Role

To use the same conditions to activate multiple roles, select Activate Role for each role you want to specify.

Activate Selected Role

Select Activate Selected Role when you want to obtain the role value from an external source. Select one of the following:

LDAP Attribute: If you have an LDAP attribute that is a role, select the attribute from the list. If the attribute is not in the list, select New LDAP Attribute to add it to the list.

LDAP Group: Activates a role based on an LDAP Group attribute. Select either [Current] or browse to the DN of the group by selecting the Identity Server and User Store. The value for this option is the DN of the group. If you select [Current], the value can be a list of the groups the user belongs to. The [Current] value makes the DN of each group in the attribute into a role.

If you select to browse to the DN of the group and you have more than 250 groups in your tree, you are prompted to enter an LDAP query string. In the text box, you need to add only the <strFilter> value for the query. For example:

<strFilter> Value	Description
admin*	Returns all groups that begin with admin, such as adminPR, adminBG, and adminWTH.
*test	Returns all groups that end with test, such as doctest, softtest, and securtest.
low	Returns all groups that have “low” in the name, such as low, yellow, and clowns.

For more information about the <strFilter> parameter, see RFC 2254 “LDAP Search Filter.”

This action does not query all the static and dynamic groups on the LDAP server to see if the user belongs to them, but uses the user’s group membership attribute to create the list. If you want to use this longer query, you need to create a policy extension. For a sample extension that does this, see Access Manager SDK Sample Code.

LDAP OU: Activates a role based on the Organizational Unit in the user’s DN. Select either [Current] or browse to the DN of the OU by selecting the Identity Server and User Store. The value for this option is the DN of the OU.

If you select to browse to the DN of the OU and you have more than 250 OUs defined in your tree, you are prompted to enter an LDAP query string. In the text box, you need to add only the <strFilter> value for the query. For example:

<strFilter> Value	Description
admin*	Returns all OUs that begin with admin, such as adminPR, adminBG, and adminWTH.
*test	Returns all OUs that end with test, such as doctest, softtest, and securtest.
low	Returns all OUs that have “low” in the name, such as low, yellow, and clowns.

For more information about the <strFilter> parameter, see RFC 2254 “LDAP Search Filter.”

Liberty User Profile: If you have a Liberty attribute that is a role, select the attribute from the list.
Data Extension: If you have created a data extension that calculates a set of roles, select the extension. For information about creating such an extension, see Access Manager SDK Sample Code.

If the source contains multiple values, select the format that is used to separate the values.

If the value is a distinguished name, select the format of the DN.

Figure 6-9 shows how to assign an LDAP Group, cn=DocGroup,o=novell, as a role.

Figure 6-9 Activating a Role from an External Source

To use the same conditions to activate multiple roles from different sources, select Activate Selected Role for each role you want to activate.

6.2.4 Example Role Policies

The following examples describe how to create a general Employee role, a restrictive Manager role, and a role from a contract with ORed credentials. These roles can be used by the Access Gateway in Identity Injection policies and by the Access Gateway in Authorization policies.

Creating an Employee Role

The following role policy creates an Employee role. Because the role does not include conditions, all authenticated users are assigned to this role when they log in. This role can then be used to grant access to resources to all users in your user stores.

In the Administration Console, click Devices > Identity Servers > Edit > Roles > Manage Policies.
On the Policies page, click New.
Select a policy type of Identity Server: Roles and specify a display name, such as Employee.
Click OK.
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 your 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.
Ensure that the Condition Group 1 section has no conditions, so that all users who authenticate match the condition.
In the Actions section, click New > Activate Role.
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.
On the Rule List page, click OK.
On the Policies page, click Apply Changes, then click Close.
On the Role Policy page, select the Employee role, then click Enable.
Click OK, then update the Identity Server.

The Identity Server configuration must be updated after you enable a role.
To create a Manager role, continue with Creating a Manager Role.

Creating a 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.

In the Administration Console, click Devices > Identity Servers > Edit > Roles > Manage Policies.
On the Policies page, click New.
Select a policy type of Identity Server: Roles and specify a display name (for this example, Manager.)
Click OK.
In the Conditions section, click New > Liberty User Profile.
In 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.

If these options are not available, you haven’t enabled the Liberty attributes. Click Identity Servers > Edit > Liberty > Web Service Provider, then enable one or more of the following: Employee Profile or Personal Profile.

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.
In the Actions section, click Activate Role.
In the Activate Role box, type Manager, then click OK twice.
On the Policies page, click Apply Changes.
Click Close, select the Manager role, then click Enable.
Click OK, then update the Identity Server.

Creating a Rule for a Contract with ORed Credentials

A contract with ORed credentials allows the user to decide which credentials to use for authenticating. If you are creating a role policy that grants the user the role regardless of which method was used for authentication, you can use such a contract just as you would any other contract in a condition. However, if you want to base the condition on the user using the contract with multiple credentials for authentication and on the user authenticating with a particular credential (password, token, or certificate), you need to create a rule with two conditions: one condition checks for the contract and the second condition checks for the authenticating credential.

If the contract with ORed credentials was named OringContracts, the first condition in the rule should look similar to the following:

Figure 6-10 Checking for the Contract

This condition verifies that the user used the OringContracts contract for authentication. The second condition needs to verify the type of credential that was used. To do this, you need to check for the existence of the credential in the Credential Profile. This condition should look similar to the following if you are verifying that the user used a certificate for the credential.

Figure 6-11 Checking for the Credential

The policy engine evaluates the above condition to true when the Credential Profile contains a value for the certificate. If the user used another method for authentication, the certificate field is empty, and the policy engine evaluates two null entries to false.

This type of condition works for the LDAP credentials and the X.509 credentials. It does not work for the Radius token, because the Credential Profile does not store the Radius token. You need to use “If Not” logic to verify that the user authenticated with a token. For example, if the OringContracts contract ORed the Radius token class with the Name/Password class, you would know that the user authenticated with a token when the password credential has no value. This type of condition should look similar to the following:

Figure 6-12 Using “If Not” Logic

If the Credential Profile contains a value for the password, this condition evaluates to false because of the “And If Not” logic. If the password value in the Credential Profile is empty, this condition evaluates to true, and you know that the user authenticated with a Radius token.

6.2.5 Creating Access Manager Roles in an Existing Role-Based Policy System

If you have already implemented a role-based administration policy for granting access to print, file, and LDAP resources, you can leverage your role definitions and use Access Manager policies to control access to Web resources. If your role definitions use the following types of LDAP features, you can create Access Manager Role policies that use them:

Values found in LDAP attributes
Location of the user objects in the directory tree
Membership in groups or roles

The Access Manager Role policies that you create for these features can then be used to control access to protected Web resources. You can manually assign the roles by creating role policies with conditions or you can activate roles based on the values in the external source.

Activating Roles from External Sources

If you have an LDAP attribute, an LDAP group, an LDAP OU, or a Liberty attribute that you are currently using for role assignments, you can have Access Manager read its value and activate roles based on the values. This allows you to use the same roles for Access Manager access as you are using in other parts of your deployment.

When you create this type of Role policy, you do not need to specify any conditions. The policy engine reads the attribute you specify, then assigns roles to users based on the value or values in the attribute. If the user has no value for the attribute, the user is assigned no roles. If the user has a value for the attribute, the user is assigned a role for each value in the attribute.

In the Administration Console, click Policies > Policies.
Select the policy container, then click New to create a new policy.
Specify a name for the Role policy, select Identity Server: Roles for the type, then click OK.
On the Rule page in the Actions section, click New > Activate Selected Role.
For this example, select LDAP Group.
To select the group you want to use for role assignments, click Current > [Identity Server Name] > [User Store Name] > [Group Name].

The distinguished name of this group is the Role name that is assigned to the user.
Select a Multi-Value Separator that is compatible with a distinguished name.

A comma, which is the default separator, cannot be used because a comma is used to separate the components in a distinguished name. Select any other value, such as #.

Your policy should look similar to the following:
Click OK twice, then click Apply Changes.
To enable the role so that it can be used in Authorization and Identity Injection policies, click Devices > Identity Servers > Edit > Roles.
Select the check box next to the name of the role, then click Enable.
Click OK.
Update the Identity Server.

(Optional) Verify the name used for the role and the user assigned to it:

Enable logging by clicking Devices > Identity Servers > Edit > Logging, then set the following values:

File Logging: Select Enabled.

Echo To Console: Select this option to enable it.

Application: In the Component File Logger Levels section, set to info.
Click OK, then update the Identity Server.
Log in to the Identity Server by using the credentials of a user who belongs the LDAP group.
View the log file for the Identity Server by clicking Auditing > General Logging
Select the file (for Windows, select the stdout.log file; for Linux, select the catalina.out file), then click Download.

Look for two log entries (<amLogEntry>) similar to the following:

<amLogEntry> 2009-10-09T21:58:55Z INFO NIDS Application: AM#500199050:
AMDEVICEID#CA50FD51DB1EEE3E: AMAUTHID#213E610199A14CEAF27395A6B35F3162:
IDP RolesPep.evaluate(), policy trace:
   ~~RL~1~~~~Rule Count: 1~~Success(67)
   ~~RU~RuleID_1223587171711~LDAP_Group~DNF~~0:1~~Success(67)
   ~~PA~ActionID_1223588319336~~AddSelectedRoles~cn=Doc~~~Success(0)
   ~~PA~ActionID_1223588319336~~AddSelectedRoles~o=novell~~~Success(0)
   ~~PC~ActionID_1223588319336~~Document=(ou=xpemlPEP,ou=mastercdn,
ou=ContentPublisherContainer,ou=Partition,ou=PartitionsContainer,
ou=VCDN_Root,ou=accessManagerContainer,o=novell:romaContentCollection
XMLDoc),Policy=(LDAP_Group),Rule=(1::RuleID_1223587171711),Action=
(AddSelectedRole::ActionID_1223588319336)~~~~Success(0)
 </amLogEntry>

<amLogEntry> 2009-10-09T21:58:55Z INFO NIDS Application: AM#500105013:
AMDEVICEID#CA50FD51DB1EEE3E: AMAUTHID#213E610199A14CEAF27395A6B35F3162:
Authenticated user cn=jwilson,o=novell in User Store Internal with roles
"cn=Doc,o=novell","authenticated".
</amLogEntry>

The first <amLogEntry> entry indicates that the action in the LDAP_Group policy was successfully assigned.

The second entry gives the DN of the user and lists the roles assigned to the user: cn=Doc,o=novell and authenticated.

You can now use the cn=Doc,o=novell role when creating Authorization and Identity Injection policies, which control access to protected Web resources. Roles activated this way do not appear in the list of available roles. You need to use the Data Entry Field to manually type in the role name. For more information, see the following:

Using Conditions to Assign Roles

Creating a Role by Using an LDAP Attribute

You can assign a user to a role by using a value found in any LDAP attribute in your directory. The following example uses the objectClass attribute because every object in an LDAP directory has an objectClass attribute that contains the object classes to which the object belongs. This attribute contains the name of the object class that was used to create the object as well as the names of the superior object classes of this class. All you need to know is the name of the object class you used to create your users in the LDAP directory. For example, the following instructions create a Role policy for users who were created with the User object class.

In the Administration Console, click Policies > Policies.
Select the policy container, then click New.
Specify a name for the Role policy, select Identity Server: Roles for the type, then click OK.
In Condition Group 1, click New, then select LDAP Attribute.
In Condition Group 1, select the conditions the user must meet:

LDAP Attribute: Select the objectClass attribute. If you have not added this attribute, it won’t appear in the list. Scroll to the bottom of the list, click New LDAP Attribute, specify objectClass for the name, then click OK.

If you are using eDirectory™ for your LDAP directory, you need to specify standard LDAP names for the attributes. Access Manager does not support spaces or colons in attribute names.

Comparison: Select how you want the attribute values to be compared. For the objectClass attribute, select String > Contains Substring.

The objectClass attribute is a multi-valued attribute and, for most objects, contains multiple values. For example in eDirectory, users created with the User object class have User, organizationalPerson, person, ndsLoginProperties, and top as values in the objectClass attribute.

Mode: Select Case Insensitive.

Value: Select Data Entry Field and specify User as the value.

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 UserClass if the condition evaluates to True. If an error occurs, you do not want random users assigned the role of UserClass. Therefore, for this rule, you need to select False.
In the Actions section, click Activate Role.
In the Activate Role box, type UserClass, then click OK.

The name you specify in the box is the role you want assigned to the users who match the condition.

Your rule should look similar to the following:
Click OK twice, then click Apply Changes.
To enable the role so that it can be used in Authorization and Identity Injection policies, click Identity Servers > Edit > Roles.
Select the check box next to the name of the role, then click Enable.
Click OK.
Update the Identity Server.

You can now use this role when creating Authorization and Identity Injection policies, which control access to protected Web resources. For more information, see the following:

Creating a Role by Using the Location of the User Objects

If you have created your users in specific containers in your LDAP tree, you can use these container objects to assign users to roles. For example, suppose your LDAP tree looks similar to the following tree.

Figure 6-13 Using an eDirectory Tree for Access Control

Such a tree organization can be used to control access to resources. The following instructions explain how to create a Role policy for the users created under the Sales container.

In the Administration Console, click Policies > Policies.
Select the policy container, then click New.
Specify a name for the Role policy, select Identity Server: Roles for the type, then click OK.
In Condition Group 1, click New, and select LDAP OU > [Identity Server Configuration] > [User Store] > [DN of the OU].

The following example illustrates how to make these selections:

Comparison: Select how you want the attribute values to be compared. For LDAP OU, select Contains.

Mode: Select One Level if all your users are created in ou=Sales. Select Subtree if your users are created in various containers under the ou=Sales container.

Value: Select LDAP OU, then select [Current].

The DN of the authenticated user is compared with the value specified in LDAP OU. If the DN of the user contains the LDAP OU value, the user matches the condition. For example, if the DN of the user is cn=bsmith,ou=sales,o=novell and the LDAP OU value is ou=sales,o=novell, the user matches the condition. If you selected Subtree for the Mode, a user with the following DN also matches the condition: cn=djones,ou=provo,ou=sales,o=novell.

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 Sales if the condition evaluates to True. If an error occurs, you do not want random users assigned the role of Sales. Therefore, for this rule, you need to select False.
In the Actions section, click Activate Role.
In the Activate Role box, type Sales, then click OK.

The name you specify in the box is the role you want assigned to the users who match the condition.

Your rule should look similar to the following:
Click OK twice, then click Apply Changes.
To enable the role so that it can be used in Authorization and Identity Injection policies, click Devices > Identity Servers > Edit > Roles.
Select the check box next to the name of the role, then click Enable.
Click OK.
Update the Identity Server.

You can now use this role when creating Authorization and Identity Injection policies, which control access to protected Web resources. For more information, see the following:

Creating a Role by Using a Group Membership Attribute

If you have created an LDAP group and assigned users to the group, you can use group membership to assign a role to the user. For example, you might have created a first-level managers group and made all your first-level managers members of this group. You can then have other groups for your upper-level managers. You can create a Role policy that assigns the user a role if the user is a member of a specific group. The Role policy can then be used in an Authorization or Identity Injection policy to protect a Web resource.

In the Administration Console, click Policies > Policies.
Select the policy container, then click New.
Specify a name for the Role policy, select Identity Server: Roles for the type, then click OK.
In Condition Group 1, click New, then select LDAP Group.
In Condition Group 1, select the conditions the user must meet:

LDAP Group: Select the Identity Server Configuration, the user store, then the Group.

The following figure illustrates this selection process.

Comparison: Select how you want the attribute values to be compared. For LDAP Group, select Is Member of.

Value: Select LDAP Group, then select [Current].

The DN of the authenticated user is compared with the members of the LDAP Group. If the DN of the user matches one of the members, the user matches the condition.

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 ManagersGroup if the condition evaluates to True. If an error occurs, you do not want random users assigned the role of ManagersGroup. Therefore, for this rule, you need to select False.
In the Actions section, click Activate Role.
In the Activate Role box, type ManagersGroup, then click OK.

The name you enter in the box is the role you want assigned to the users who match the condition.

Your rule should look similar to the following:
Click OK twice, then click Apply Changes.
To enable the role so that it can be used in Authorization and Identity Injection policies, click Devices > Identity Servers > Servers > Edit > Roles.
Select the check box next to the name of the role, then click Enable.
Click OK.
Update the Identity Server.

You can now use this role when creating Authorization and Identity Injection policies, which control access to protected Web resources. For more information, see:

6.2.6 Mapping Roles between Trusted Providers

The Identity Server can send roles in an authentication assertion. You can map these roles that are received from trusted providers to your own roles. Figure 6-14 illustrates this process.

Figure 6-14 Role Mapping

In this example, employees authenticate to identity providers novell.com (Liberty) or xyz.com (SAML 2.0). Each user is assigned to a role, such as N_EmployeeRole or XYZ_Empl. Attribute sets at each of the identity providers are configured to exchange the All Roles attribute with the trusted service provider, DigitalAirlines.com. DigitalAirlines.com consumes the authentication assertions, then maps the incoming roles to local roles. The mapped roles at DigitalAirlines.com can be used as evaluated conditions in authorization policies, which can provide access to resources intended for the authenticated employees.

Prerequisites

Configure trust between trusted providers, using the Liberty or SAML 2.0 protocol.

You should be familiar with Section 5.2.4, Configuring SAML 2.0 and Section 5.2.6, Configuring Liberty.
Configure local authentication.

You must create an external contract at the service provider that matches the contract of the identity provider. See Section 5.1, Configuring Local Authentication.
Create an attribute set and select the local attribute All Roles in the set. This must be done at the identity provider and service provider.

This attribute set is used to pass roles from an identity provider to an external service provider in authentication assertions. See Section 3.5.1, Configuring Attribute Sets.

Procedure

The following procedure describes how the service provider configures this type of role policy for novell.com, mapping the N_Employee role to an Access Manager role:

In the Administration Console, click Policies > Policies.
Click New, then specify a name for the Role policy.
Select Identity Server: Roles for the type, then click OK.
Configure the role policy as shown on the following page.
In the Conditions section, click New > Roles from Identity Provider.
Select the trusted identity provider in the drop-down menu.
For Comparison, select String > Equals.
Select Value > Data Entry Field.
Type the name of the role used by the trusted identity provider.
Under the Actions section, click Activate Role.
Type the name of the role you want to activate at the trusted service provider.
Click OK.
On the Policies page, click Apply Changes.
To enable the role so that it can be used in Authorization and Identity Injection policies, click Identity Servers > Servers > Edit > Roles.
Select the check box next to the name of the role, then click Enable.
Click OK.
Update the Identity Server.

6.2.7 Enabling and Disabling Role Policies

In order for a role policy to function, you must enable it for the Identity Server configuration.

In the Administration Console, click Devices > Identity Servers > Edit > Roles.
Select the role policy’s check box, then click Enable.
To disable the role policy, select the role policy’s check box, then click Disable.
After enabling or disabling role policies, update the Identity Server configuration on the Servers tab.

6.2.8 Importing and Exporting Role Policies

You can import and export role policies in order to run them in other Identity Server configurations. When you import a role, ensure that you have enabled any Liberty profile that is referenced in the role policy, in order to correctly display the policy in the interface. However, the policy still evaluates if you have not enabled the profile.

You must also enable roles after importing them to an Identity Server configuration. See Section 6.2.7, Enabling and Disabling Role Policies. Click Devices > Identity Servers > Edit > Roles.

When you export a role policy, the system saves it as a .txt file at the location of your choosing. After you import a role policy, you must update the Identity Server configuration.

To export a role policy:

In the Administration Console, click Policies > Policies.
Select a policy, then click Export.
(Optional) Modify the name suggested for the file.
Click OK.
Using the features of your browser, specify where you want the file to be copied.
Click OK.

To import a role policy:

In the Administration Console, click Policies > Policies.
Click Import, then browse to and select the file.
Click OK.
When the policy appears in the list, click Apply Changes.