Partnership Definition

Federation Guides › Partnership Federation Guide › Partnership Creation and Activation › Partnership Definition

Partnership Definition

The federation partnership definition specifies which federation role is local, and which federation role is remote.

To specify the partnership type

Log in to the Administrative UI.
Select Federation, Partnership Federation, Partnerships.
The Federation Partnerships dialog is displayed.
Click Create Partnership in the Federation Partnership List.
Note: Click Help for a description of fields, controls, and their respective requirements.
Select one of the following partnerships:
- SAML2 IDP->SP (Identity Provider is local).
- SAML2 SP->IDP (Service Provider is local).
- SAML1.1 Producer ->Consumer (Producer is local).
- SAML1.1 Consumer ->Producer (Consumer is local).

The Partnership dialog opens at the first step in the partnership wizard.

Partnership Identification and Configuration

In the Configure Partnership step of the wizard, identify the partnership by naming the partnership and specifying the local and remote entities.

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

Follow these steps:

Enter a name for the partnership. You can use alphanumeric characters, underscores, hyphens, and periods in the name. Spaces are not allowed.
(Optional) Type a description.
Select a local entity from the local list if you have already configured an entity. If not, click Create Local Entity.
Select a remote entity from the remote list if you have already configured an entity. If not, click Create Remote Entity.
Note: This step can be deferred if you are planning to create the remote entity by importing metadata later.
(Optional) Specify a Base URL.
(Optional) Enter the Skew Time in seconds.
The skew time is the difference between the system time on the local system and the system time on the remote system. Usually, the inaccuracy of system clocks causes this condition. Determine the skew time number by subtracting the number of seconds from the current time.

The system uses the skew time and the SSO validity duration to determine how long an assertion is valid.
Select one or more user directories from the Available Directories list and move them to the Selected Directories list.
If you configure only one user directory, that directory is automatically placed in the Selected Directories list.

Important! To use an ODBC database as a user directory, define an SQL Query scheme and valid SQL queries. These steps are necessary before you can select it as a user directory.
Click Next to continue through the partnership wizard. The steps of the wizard let you configure various features of a partnership, some features are required, and some are optional. The configuration details for these features are described in subsequent sections of this guide.

Note: If you are editing a partnership, you can click Get Updates next to this field to update the entity information. The latest information from the entity configuration is propagated to the partnership. However, if you edit the entity information directly from the partnership, the changes do not get propagated back to the individual entity configuration.

Editing Entities from the Partnership

You can click Get Updates next to the local and remote entity fields to update information about the entity. When you select Get Updates, the system asks to pull in the latest information from the entity.

After confirmation, the partnership you are editing is refreshed with the latest entity information. Changes are saved when you complete the partnership wizard. If you do not confirm the update, the partnership configuration remains the same.

The Entity Name identifies an entity object for in the policy store. The Entity Name must be the unique identifier because the product uses this value internally to distinguish an entity. This value is not used externally and the remote partner is not aware of this value.

If the Entity ID represents a remote partner, the value must be unique. If the Entity ID represents a local partner, it can be reused on the same system.

Note: The Entity Name can be the same value as the Entity ID, but do not share the value with any other entity.

An entity is a key component of a federation partnership. Changing an entity alters the partnership significantly; therefore, the Administrative UI does not let you replace an entity after it is in a partnership. To replace an entity, create a partnership.

To provide some flexibility within partnership configuration, you can change an entity ID because it does not identify the entity uniquely. Changing the entity ID at the partnership level does not link the partnership to another entity. The original entity in the partnership does not change. Modifications to an entity are a one-way propagation from the entity to the partnership. A change to the entity ID at the partnership does not get propagated back to the original entity.

Regard entity configurations as templates. Partnerships are created based on the entity templates so changing the partnership does not change the original entity template.

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.

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.

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:

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
Click Help for the field descriptions,
(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.