Federation Guides › Partnership Federation Guide › Federated User Identification for a Partnership

Federated User Identification for a Partnership

This section contains the following topics:

Federation Users Configuration at the Asserting Party

User Identification at the Relying Party

Federation Users Configuration at the Asserting Party

The Federation Users dialog is the second step in the partnership wizard when the local entity is the asserting party. This step lets you specify which users are authorized to access target resources at the remote site.

Follow these steps:

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

Select a user directory from the list in the Directory column of the table of the Federated Users group box.
The pull-down list consists of one or more directory entries, depending on the number of directories you specified in the previous dialog.
Select the user class in the User Class column. This entry specifies a category of individual users or groups of users that can be authenticated. The options for this field depend on the type of user directory (LDAP or ODBC). Refer to the User Class tables for an explanation and example of each user class.
Enter a name or filter in the User Name/Filter By column. The value in this column lets the system locate the user or user group from which to authenticate federated users. This entry is dependent on the value you select for the User Class column. For examples of names and filters, see the tables at the end of this procedure.
(Optional) You can select Exclude for an entry to indicate that you want to exclude this user class. The default is to include all users in the directory.
Note: An exclude criteria always takes precedence over an include criteria in case the two criteria conflict.
(Optional) Click Add Row to specify another user class for the same directory or another user directory.

The selection of users is complete.

Examples of User Class Entries

LDAP Examples

Use the LDAP filter syntax when specifying entries.

User Class	Valid Entry
User	Distinguished name of a user. Example: uid=user1,ou=People,dc=example,dc=com
Group	Group chosen from the list. Example: ou=Sales,dc=example,dc=com
Organization Unit	Organizational unit chosen from the list. Example: ou=People,dc=example,dc=com
Filter User Property	LDAP filter. The current user is the starting point for the search. Example 1: mail=user@example.com Example 2: (\|(mail=*@.example.com)(memberOf=cn=Employees,ou=Groups,dc=example,dc=com))
Filter Group Property	LDAP filter. The current user gets authorized if they are a member of one of the groups matching the filter. The objectclasses for groups as configured in the SiteMinder registry are combined with the filter. Example 1: To authorize users that are members of a group with a business category of "CA Support", enter: businessCategory=CA Support Example 2: To authorize users that are members of a group with a description containing "Administrator" and a business category of "Administration", enter: (\|(description=Administrator)(businessCategory=Administration)) Note: Not all attributes of a group work as a search criterion.
Filter OU Property	LDAP filter. The current user gets authorized if they belong to an organizational unit that matches the filter. The objectclasses for organizational units as configured in the SiteMinder registry are combined with the filter. Example 1: To authorize users within an organizational unit with a postal code of "12345", enter: postalCode=12345 Example 2: To authorize users in an organizational unit with a preferred delivery method ending with "phone" and a locality of "London", enter: (\|(preferredDeliveryMethod=*phone)(l=London))
Filter Any	LDAP filter. The current user gets authorized if they match the filter. Example 1: To authorize users with a department of "CA Support", enter: department=CA Support Example 2: To authorize users who are members of the group "Administrators" and have a department number of "123" or "789", enter: (&(memberof=cn=Administrators,ou=Groups,dc=example,dc=com)(\|(departmentNumber=123)(departmentNumber=789)))

ODBC Examples

Use the SQL syntax when specifying queries.

User Class	Valid Entry
User	Value of the Name column for a user. The current user gets authorized if they match the entry. Example: user1
Group	Value of the Name column of a user group. The current user gets authorized if they are a member of the group that matches the query. Example: Administrators
Query	A SQL SELECT statement. The current user gets authorized if they match the query. Example 1: With a userid of user1: Entry: SELECT * FROM SmUser Resulting query: SELECT * FROM SmUser WHERE Name = 'user1' Example 2: With a userid of user1: Entry: SELECT * FROM SmUser WHERE Status LIKE 'Active%' Resulting query: SELECT * FROM SmUser WHERE Status LIKE 'Active%' AND Name = 'user1' Example 3: With a userid of user1: Entry: SELECT * FROM SmUser WHERE Location IN ('London', 'Paris') Resulting query: SELECT * FROM SmUser WHERE Location IN ('London', 'Paris') AND Name = 'user1'

User Class

Valid Entry

User

Value of the Name column for a user. The current user gets authorized if they match the entry.

Example: user1

Group

Value of the Name column of a user group. The current user gets authorized if they are a member of the group that matches the query.

Example: Administrators

Query

A SQL SELECT statement. The current user gets authorized if they match the query.

Example 1: With a userid of user1:

Entry: SELECT * FROM SmUser

Resulting query: SELECT * FROM SmUser WHERE Name = 'user1'

Example 2: With a userid of user1:

Entry: SELECT * FROM SmUser WHERE Status LIKE 'Active%'

Resulting query: SELECT * FROM SmUser WHERE Status LIKE 'Active%' AND Name = 'user1'

Example 3: With a userid of user1:

Entry: SELECT * FROM SmUser WHERE Location IN ('London', 'Paris')

Resulting query: SELECT * FROM SmUser WHERE Location IN ('London', 'Paris') AND Name = 'user1'

User Identification at the Relying Party

At the relying party, the partner must be able to locate a user in the local user directory. Locating the user in the user directory is the process of disambiguation. Configure the identity attribute for user disambiguation in the User Identification dialog.

The Policy Server can use one of the following methods for the disambiguation process:

Extract the Name ID value from the assertion.
Use the value of a specific attribute from the assertion.
Use the value that the Xpath query obtains.
The Xpath query locates and extracts an attribute other than the Name ID from the assertion.

After you determine which attribute is extracted from the assertion, include this attribute in a search specification. After a successful disambiguation process, the Policy Server generates a session for the user.

For SAML 2.0, you can also configure the AllowCreate feature, which lets an asserting party create a user identifier.

Configure User Identification at the Relying Party

Configure user identification so the relying party has a method of locating a user in the local user directory.

Follow these steps:

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

Select one of the following attributes for disambiguation:
- Name ID
- An attribute from a previously populated drop-down list
  If the remote asserting entity was created based on metadata that contained attributes, the list is populated.
- An attribute you enter.
  This option is most likely used when metadata is not available and the remote asserting entity does not include any attributes.
- An Xpath query
(Optional—SAML 2.0 only) Select Allow IDP to create user identifier.
This attribute instructs the asserting party to generate a new value for the NameID, if this feature is enabled at the asserting party. The Name ID Format entry at the asserting party must be a persistent identifier.
(Optional—SAML 2.0 only) Select Query parameter overrides identifier.
This setting lets the relying party send an AllowCreate query parameter to override the value of the AllowCreate attribute configured in the authentication request. Using the query parameter instead of the identifier lets you change the value of the AllowCreate attribute without altering the partnership configuration.

Note: For the Identity Provider to honor this query parameter setting, select the Allow IDP to create user identifier check box.
Specify a directory search specification for each directory listed. Two examples of search specifications are:

LDAP Example

uid=%s

ODBC Example

name=%s
Click Next to continue with the partnership configuration.

Employ AllowCreate for User Identification (SAML 2.0)

The SAML 2.0 AllowCreate feature is an optional setting in the User Identification configuration at the SP. Including an AllowCreate attribute in an authentication request lets an Identity Provider create a user identifier for the SP.

An SP can initiate single sign-on by sending an authentication request to the Identity Provider. As part of the request, a Service Provider can include an attribute named AllowCreate, which is set to true. The Service Provider wants to obtain an identity for the user. Upon receiving the AuthnRequest, the Identity Provider generates an assertion. The Identity Provider searches the appropriate user record for the assertion attribute serving as the Name ID. If the Identity Provider cannot find a value for the NameID attribute, it generates a unique persistent identifier for the NameID. Enable the Allow/Create feature at the Identity Provider for it to generate the identifier. The Identity Provider returns the assertion with the unique identifier back to the SP.

You can enable an AllowCreate query parameter to supersede the value of the AllowCreate attribute. Use of a query parameter lets you override the configured AllowCreate setting without deactivating, editing, and reactivating the partnership. The query parameter makes the implementation of the feature more flexible.