User Identification for a Partnership

You configure how to identify users for a federated partnership at the asserting and relying parties. User configuration at each side of a partnership is explained in this topic.
sm1252sp1
You configure how to identify users for a federated partnership at the asserting and relying parties. User configuration at each side of a partnership is explained in this topic.
2
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:
  1. 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.
  2. 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.
  3. 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.
  4. (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.
    An exclude criteria always takes precedence over an include criteria in case the two criteria conflict.
  5. (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:
[email protected]
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
CA Single Sign-On
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
CA Single Sign-On
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 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 as part of the user identification configuration. This feature instructs an IdP create a user identifier for the NameID if none exists in the user record at the IdP.
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:
  1. 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
  2. (Optional—SAML 2.0 only) Select
    Allow IDP to create user identifier
    to instruct the asserting party to generate a new value for the NameID. 
    The SP can send an authentication request that includes an AllowCreate attribute set to "true." Upon receiving the AuthnRequest, the Identity Provider searches the appropriate user record so it can supply the assertion attribute acting as the Name ID. If the Identity Provider cannot find a value, and the AllowCreate feature is enabled, the Identity Provider  generates a unique persistent identifier for the Name ID. The Identity Provider returns the assertion with the unique identifier back to the SP. The Name ID Format entry at the asserting party must be a persistent identifier.
  3. (Optional) Select a format from
    NameIDPolicy Format
    to include a format attribute in the NameIDPolicy tag in AuthnRequest sent to IDP.
    When
    Allow IDP to create user identifier
    is selected and a value is selected from
    NameIDPolicy Format
    , the selected format is sent.
    When
    Allow IDP to create user identifier
    is not selected and no value is selected from
    NameIDPolicy Format
    , no format is sent.
    When
    Allow IDP to create user identifier
    is not selected and a value is selected from
    NameIDPolicy Format
    , the selected format is sent.
    When
    Allow IDP to create user identifier
    is selected and no value is selected from
    NameID Policy Format
    , the Persistent format is sent.
  4. (Optional—SAML 2.0 only) Select
    Query parameter overrides identifier
    to enable a query parameter to replace the value of the AllowCreate attribute in the AuthnRequest. 
    You can include a AllowCreate query parameter in the initiating URL to the AuthnRequest service at the SP. If an AllowCreate attribute already exists in the AuthnRequest, the value of the query parameter replaces the value of the attribute. The benefit of the query parameter is that you change the value of the AllowCreate attribute without altering and reactivating the partnership configuration. 
  5. Specify a directory search specification for each directory listed. Two examples of search specifications are:
    • LDAP Example
      uid=%s
    • ODBC Example
      name=%s
  6. Click Next to continue with the partnership configuration.