CA SiteMinder® Federation Standalone Guide › User Directory Connections for Authentication › Create a Common View of the Same User Information Across Directories

Create a Common View of the Same User Information Across Directories

Directory connections resolve how CA SiteMinder® Federation Standalone establishes a context for user identities. The asserting party determines which users it can create assertions for by authenticating each user against a user directory.

Multiple user directories in a federated environment often store the same type of user information, but each directory uses a different underlying schema and different user attribute names to identify the information. Therefore, CA SiteMinder® Federation Standalone receives a disparate view of the same user information. For example, an LDAP directory can use the attribute uid to represent a user name, whereas an ODBC directory can use the attribute name for the same information.

The purpose of user attribute mapping is to create a common view of the same information by defining a universal schema. The universal schema can resolve user information across multiple user directories. The system can reference user attributes without regard for the directory type, greatly reducing the number of configuration objects that are required for multiple user directories.

Each user attribute mapping is specific to the user directory in which it is defined.

After the connections to the user directories are configured, use one common name to reference the same information in different user directories.

The feature that you use to create a universal schema is called user attribute mapping. Configure this feature within the user directory configuration of the Administrative UI.

The following graphic shows the process for configuring user attribute mapping at the asserting party.

Complete the following tasks at the asserting party for user attribute mapping:

1. Establish connections to user directories.
2. Configure user attribute mappings.
3. Apply mappings as assertion attributes.

Establish Connections to User Directories

Before you can establish user attribute mappings, establish connections to the user directories that store user records.

LDAP or ODBC are the two types of directories to which the product can connect.

Follow these steps:

1. Click the User Directory tab.
2. Click Connect to LDAP or ODBC.
3. Configure the settings in each section. Required parameters are marked by red dots.

   Note: Click Help for a description of fields, controls, and their respective requirements.

4. Click Failover or Load Balancing if you want to set up either of these features.
5. Click Test Connection to verify that the connection is valid.

   You can click View Contents to list the contents of the user directory.

   Note:

   • For an LDAP directory connection, the View Contents button is displayed only if the Search Root, Start User DN Lookup, End User DN Lookup, and Universal ID Attribute values are set.
   • For an ODBC directory connection, the View Contents button is displayed only if the Universal ID Column value is set.
6. Click Save.

   If your settings are valid, you are redirected to the View User Directories dialog.

   The connection to the directory is configured.

Configure User Attribute Mappings

Use one or more of the following mapping types to define attribute mappings:

• Alias
• Group Name
• Mask
• Constant
• Expression

The following table lists the type of data you can enter in the mapping definition. Define individual mappings for each user directory in your deployment.

The configuration procedures for each mapping type are basically the same. Refer to the use cases for each mapping type for implementation examples.

Follow these steps:

1. In the Administrative UI, navigate to the User Directory tab.
2. Select one of the Connect to options in the User Directory List.
3. Verify that a user directory connection is configured or configure one.
4. Scroll to the Directory Mapping Attribute section and select Create Mapping.
5. Complete the General fields:

   Name

   Specify the common name for this mapping. Common names must conform to the same rules as user attribute names.

   Description

   Enter a description of the attribute mapping.

6. Complete the Properties fields:

   Mapping type

   Select the mapping type that you want to configure.

   Definition

   Enter the mapping definition using the appropriate syntax. Refer to the previous table.

7. (Optional) Select Disabled to disable an attribute mapping.
8. Click Save.

The new attribute mapping is submitted and then added to the list on the Attribute Mapping List table.

Alias Attribute Use Case

This use case shows two LDAP user directories, which identify the last name of users, but the directories have different underlying schema.

Note: Review the advanced user attribute mapping examples, which detail how to use different attribute mapping types to identify the same user attribute across different directory types.

The following illustration details how two alias attribute mappings can create a common view of the same user information.

1. Two user directories identify the last name of users differently:
   • Directory A identifies the last name of users with sn.
   • Directory B identifies the last name of users with lastname.

   This results in two different views of the same user information.

2. LastName is the common name or alias that is mapped to the underlying directory schema:
   • LastName is mapped to sn in Directory A.
   • LastName is mapped to lastname in Directory B.

LastName results in a common view of the same user information. Use LastName when defining assertion attributes or NameID attributes that use the last names. The system has no concern for the directory-specific schema because the directories are operationally identical.

More information:

Advanced User Attribute Mapping Examples

Group Name Use Case

This use case shows two LDAP user directories, which use different underlying schema to identify users that belong to an Administrator group.

Note: Review the advanced user attribute mapping examples, which detail how to use different attribute mapping types to identify the same user attribute across different directory types.

The following illustration details how two group name attribute mappings can create a common view of the same user information.

1. Two user directories identify membership to the administrator group differently:
   • Directory A identifies membership in the administrator group as cn=Administrators,ou=groups,o=acme.com.
   • Directory B identifies membership in the administrator group as cn=Admin,ou=groups,o=acme.com.

   This results in two different views of the same user information.

2. IsAdmin is the common name that is mapped to the underlying directory schema:
   • IsAdmin is mapped to cn=Administrators,ou=groups,o=acme.com in Directory A.
   • IsAdmin is mapped to cn=Admin,ou=group,o=acme.com in Directory B.

IsAdmin results in a common view of the administrator group. You can reference IsAdmin when defining assertion attributes or NameID attributes that apply to the Administrator group. The system has no concern for the directory-specific schema because the directories are operationally identical.

More information:

Advanced User Attribute Mapping Examples

Mask Use Case

Some directory implementations use individual bits in an attribute to provide information about that attribute, such as the state of an account. You can apply a bit mask to an attribute.

This use case shows two Active Directory user stores that identify disabled user accounts. Each account has a different underlying schema.

Note: Review the advanced user attribute mapping examples, which detail how to use different attribute mapping types to identify the same user attribute across different directory types.

The following illustration details how two mask attribute mappings can create a common view of the same user information.

1. Two user directories contain a user attribute named AccountStatus. AccountStatus stores user information in a bit pattern, where each bit is a flag.
   • In Directory A, the second bit flags a disabled account. When the second bit equals 1, the account is disabled.
   • In Directory B, the third bit flags a disabled account. When the third bit equals 1, the account is disabled.

   This results in two different views of the same user information.

2. IsDisabled is the common name that is mapped to the underlying directory schema. In both directories, IsDisabled is mapped to AccountStatus.
   • In Directory A, the bit mask 2 (decimal) determines whether the second bit of AccountStatus is set and the account is disabled.
   • In Directory B, bit mask 4 (decimal) determines whether the third bit of AccountStatus is set and the account is disabled.

IsDisabled results in a common view of disabled user accounts. You can reference IsDisabled when defining assertion attributes or NameID attributes that require the account status of users. The system has no concern for the directory-specific schema because the directories are operationally identical.

More information:

Advanced User Attribute Mapping Examples

Bit Masks in Mask Attribute Mapping

A bit mask attribute mapping tests the value of one or more bits by masking the values of the other bits in a user attribute.

A mask attribute mapping is defined as follows:

user_attribute_name:bit_mask

For example, assume that the user attribute is named AccountStatus. The attribute AccountStatus stores the states of the following three flags in a bit pattern:

When a bit equals one, the flag is TRUE. The table shows the results:

Note: Equivalent decimal values are shown in parentheses.

Assume that you only want to test whether a user is a gold member. To test this bit, select the bit pattern that corresponds to a gold member as the bit mask or 100 (binary) and specify it as 4 (decimal). The resulting mask attribute mapping is defined as follows:

AccountStatus:4

A bitwise AND operation on AccountStatus is performed on the bit mask and tests whether the result is equal to the bit mask. An equal result means the value of the tested bit is one and the flag is TRUE. The following table shows the results:

Note: Equivalent decimal values are shown in parentheses.

You can also use a bit mask to test the value of a bit set or more than one bit at a time. Assume that you want to know whether the account is disabled and the password has expired. To test these bits, specify a bit mask of 011 (binary) or 3 (decimal). The resulting mask attribute mapping is defined as follows:

AccountStatus:3

A bitwise AND operation on AccountStatus is performed on the bit mask and tests whether the result is equal to the bit mask. An equal result means the value of both tested bits is one and both flags are TRUE. The following table shows the results:

Note: Equivalent decimal values are shown in parentheses.

Constant Use Case

This use case represents a scenario in which one user directory stores only customers, while another user directory stores only employees.

Note: Review the advanced user attribute mapping examples, which detail how to use different attribute mapping types to identify the same user attribute across different directory types.

The following illustration details how two constant attribute mappings can represent different values for different user directories.

1. Directory A only stores customers. Directory B only stores employees.
2. IsCust is the common name that is mapped to different values in different directories:
   • IsCust is mapped to TRUE in Directory A.
   • IsCust is mapped to FALSE in Directory B.
3. Reference IsCust when defining assertion attributes or NameID attributes. The common name lets the system determine whether a user is a customer, without regard to the particular directory in which the user is stored. The mapping indicates that every user in Directory A is a customer, while every user in Directory B is not a customer.

Expression Use Case

This use case shows how you can use an expression attribute mapping to simplify references to multiple user attributes in one directory. A protected resource needs the sort name of each user (last name,first name). The user directory does not uniquely reference this attribute. Instead, the directory does store the last name of each user as surname and the first name of each user as givenname.

The following illustration details how an expression attribute mapping can create a common view of the same user information.

In the single user directory, a common name is mapped to an expression that creates the sort name using the user attribute names in the directory.

• Directory A contains all user records.
• The name of the mapping is SortName.
• The expression that defines SortName is:

  {surname + "," + givenname}
  

  Note: The expression conforms to the syntax rules of a CA SiteMinder® expression. For complete syntax information, see the Attributes and Expression Reference appendix in the SiteMinder Policy Server Configuration Guide in the SiteMinder bookshelf.

• SortName is the common name that is mapped to the expression that includes the surname and the givenname attributes.

Reference SortName when defining assertion attributes or NameID attributes that require the sort name of users without concern for the directory-specific schema.

Advanced User Attribute Mapping Examples

The following examples show more complex user attribute mapping configurations.

The example deployment is a retail clothing company that uses two user directories of different types:

Directory A

An internal LDAP user directory for employees only.

Directory B

An ODBC user directory for customers only.

Each user attribute mapping is specific to the user directory for which it is defined.

The following table details how Directory A and Directory B identify the same user information. The accompanying use cases explain how to use different attribute mappings to define a common view of the same user information. The common view serves as a universal schema, which makes the directories operationally identical.

Map a First Name Attribute with an Alias Mapping Type

Use two alias attribute mappings to represent the first name user attribute in Directory A and Directory B.

Deployment

User Directory A identifies the first name of users with givenname. Directory B identifies the first name of users with u_first_name.

Solution

1. Create an alias attribute mapping for Directory A.

   Name

   FirstName

   Mapping Type

   Alias

   Definition

   givenname

2. Create an alias attribute mapping for Directory B.

   Name

   FirstName

   Mapping Type

   Alias

   Definition

   u_first_name

When referencing users in Directory A, the FirstName is mapped to givenname. When referencing users in Directory B, the FirstName maps to u_first_name.

Map a Last Name Attribute with an Alias Mapping Type

Use two alias attribute mappings to represent the last name user attribute in Directory A and Directory B.

Deployment

User Directory A identifies the last name of users with surname. Directory B identifies the last name of users with u_last_name.

Solution

1. Create an alias attribute mapping for Directory A.

   Name

   LastName

   Mapping Type

   Alias

   Definition

   surname

2. Create an alias attribute mapping for Directory B.

   Name

   LastName

   Mapping Type

   Alias

   Definition

   u_last_name

When referencing users in Directory A, the common view determines that the last name of users is identified by surname. When referencing users in Directory B, the common view determines that the last name is identified by u_last_name.

Map a Sort Name Attribute with Expression and Alias Mapping Types

Use an expression attribute mapping and an alias attribute mapping to represent the sort name of a user in Directory A and Directory B.

Deployment

• Directory A does not uniquely identify the sort name for each user. For each user, Directory A stores the first name as givenname and a last name as surname for each user.
• Directory B identifies a sort name using sort_name.

Solution

1. Create an expression attribute mapping for Directory A:

   Name

   SortName

   Mapping Type

   Expression

   Definition

   (surname + "," + givenname)
   

   Note: The expression must conform to the syntax rules of an expression.

2. Create an alias attribute mapping for Directory B:

   Name

   SortName

   Mapping Type

   Alias

   Definition

   sort_name

When referencing users in Directory A, the sort name is calculated based on the specified expression. When referencing users in Directory B, the sort name is represented by the attribute sort_name.

Map Customers with Group and Constant Mapping Types

Use a group and a constant attribute mapping to identify customers in Directory A and Directory B.

Deployment

• Directory A stores employee. An employee of the company can also be a customer, so Directory A identifies customers as those employees that belong to the following group:

  cn=Customers,ou=Groups,o=acme.com
  

• Directory B only stores customers. Directory B does not have a user attribute that identifies customers.Storing a user in Directory B implies that the user is a customer.

Solution

1. Create a group attribute mapping for Directory A.

   Name

   IsCustomer

   Mapping Type

   Group

   Definition

   cn=Customers,ou=Groups,o=acme.com
   

2. Create a constant attribute mapping for Directory B.

   Name

   IsCustomer

   Mapping Type

   Constant

   Definition

   TRUE

When referencing Directory A, a user is considered a customer if they belong to cn=Customers,ou=Groups,o=acme.com. When referencing Directory B, every user is a customer.

Map the Account Status with the Mask and Expression Mapping Types

Use a mask attribute mapping and an expression attribute mapping to identify user accounts that are disabled in Directory A and Directory B.

Deployment

• Directory A identifies disabled accounts with a user attribute named AccountStatus, which is a set of flags. The second bit indicates a disabled account.
• Directory B identifies disabled accounts with a user attribute named u_disabled. When u_disabled is equal to "y", the account is disabled. When u_disabled is equal to "n", the account is active.

Solution

1. Create a mask attribute mapping for Directory A.

   Name

   IsDisabled

   Mapping Type

   Mask

   Definition

   AccountStatus:2

   The definition indicates that the bit pattern is stored in AccountStatus, and the bit mask is 2 (decimal).

2. Create an expression attribute mapping for Directory B.

   Name

   IsDisabled

   Mapping Type

   Expression

   Definition

   (u_disabled = "y")
   

   u_disabled is a Boolean expression.

When referencing Directory A, the bit pattern determines if a user is disabled. When referencing Directory B, the expression determines if a user is disabled.

Apply Mappings to Assertion Attributes

After you define user attribute mappings for your user directories, add the user attribute mapping to the assertion configuration for the asserting-to-relying party partnership. The mapping helps the asserting party include the right attributes in the assertion, regardless of the different attributes for each directory type.

The Name ID type can be a user attribute in the assertion configuration.

Follow these steps:

1. Log on to the Administrative UI.
2. Click Federation, Partnerships.
3. Select Action, Modify for the local asserting party partnership.
4. Navigate to the Assertion Configuration tab.
5. In the Assertion Attributes section, click Add Row.
6. Enter the data from the user mappings into the fields as follows:

   Assertion Attribute

   Specify any name for the name/value pair of an assertion attribute.

   Format

   Choose the format that indicates how to interpret the attribute name.

   Type

   User attribute

   Always select the user attribute type as the value for this field.

   Value

   Enter the value from the Name field in the user mapping section of the User Directory dialog.

   Example: If the Name you assigned to a mapping is FullName, enter FullName in this field.

7. (Optional). The Name ID type can be a user attribute so make the Value field for the Name ID entry match the Value field in the assertion attribute entry. The assertion then uses the same user attribute for the Name ID and the assertion attribute that identifies the user.
8. Repeat the procedure in the previous step for all assertion attributes.
9. Navigate to the Confirm step and click Finish to save your changes.