Sun Java System Access Manager 7.1 Federation and SAML Administration Guide

Liberty ID-FF Operations

This section contains procedures illustrating how to use Access Manager to configure interactions based on the Liberty ID-FF. They are:

Auto-Federation

The auto-federation feature in Access Manager will automatically federate a user's disparate provider accounts based on a common attribute. This common attribute will be exchanged in a single sign-on assertion so that the consuming service provider can identify the user and create account federations. If auto-federation is enabled and it is deemed that a user at provider A and a user at provider B have the same value for the defined common attribute (for example, emailaddress), the two accounts will be federated automatically without principal interaction.

Note –

Auto-federating a principal's two distinct accounts at two different providers requires each provider to have agreed to implement support for this functionality beforehand.

To Enable Auto Federation

Ensure that each local service and identity provider participating in auto federation is configured for it. Remote providers would not be configured in your deployment.

In the Access Manager Console, click the Federation tab.

Under Federation, select the Entities tab.

Select the name of a hosted provider entity to edit its profile.

Whether an entity is configured to hold hosted or remote providers is not information that is disclosed on this screen.

Select Identity Provider or Service Provider from the View menu.

Select Access Manager Configuration.

Enable Auto Federation by checking the box.

Type a value for the Auto Federation Common Attribute Name attribute.

For example, enter emailaddress or userID. You should be sure that each participating user profile (at both providers) has a value for this attribute.

Click Save to complete the configuration.

Bulk Federation

Access Manager provides a script for federating user accounts in bulk. It is called ambulkfed and is located in /opt/SUNWam/bin. The script assumes that the user database is LDAPv3–compliant.

Note –

The ambulkfed script is the primary script for bulk federation. It uses two other Perl scripts, amGenerateLDIF.pl and amGenerateNI.pl, behind the scenes.

As input, the script takes a file that maps the user distinguished name (DN) of the identity provider to the user DN of the service provider. Each line of the file must place the mappings in the following order and separated by a pipe (”|”): uid=spuser,dc=iplanet,dc=com | uid=idpuser,dc=iplanet,dc=com. The script generates unique random identifiers for each mapping and creates four files:

spnameidentifiers.txt
idpnameidentifiers.txt
spuserdata.ldif
idpuserdata.ldif

These files contain the data for bulk federation. The LDIFs are used for instances of Access Manager. ambulkfed generates and loads the LDIF data into Access Manager based on its given provider role. For example, it will load spuserdata.ldif if Access Manager acts as a service provider and it will load idpuserdata.ldif if Access Manager acts as an identity provider. The LDIFs will also be stored locally and can be used with ldapmodify to load the data into a remote instance of Access Manager. If the remote provider is not an instance of Access Manager, the generated text files spnameidentifiers.txt and idpnameidentifiers.txt can be used to generate federation data based on the input needs of the provider.

Configuring Trust Between Providers

In order to complete interactions based on the Liberty ID-FF, trust must exist between all communicating providers. Each provider that wishes to be part of a federated trust model does so after complex business negotiations, the exchange of provider configuration metadata, and the configuration of trust. Using the Access Manager console, trusted providers are configured using the metadata and are then grouped (as entities) into an authentication domain. To accomplish this, you load the provider metadata, and assign the configured providers to the same authentication domain. The following procedure explains how to configure trust using either the command line interface or the Access Manager console. Additional information can be found in Entities and Authentication Domains.

To Configure Trust Between Service Providers and Identity Providers

Before You Begin

You must have metadata files specific to each provider you are configuring. Access Manager includes sample metadata XML files that you can modify for your purposes. See sample1 Directory for more information.

Load the hosted and remote provider metadata XML files to Access Manager using the amadmin command line interface.

See Creating and Configuring Entities using amadmin for information.

Under Federation, click the Authentication Domains tab.

Select New.

The new Authentication Domain attributes are displayed.

Create the authentication domain and click OK.

See To Create An Authentication Domain for information.

Under Federation, click the Entities tab.

Select the name of a provider.

The provider was created when the metadata was loaded. The General attributes for the chosen provider are displayed.

Select the appropriate provider type from the View pull down menu.

Scroll down to Authentication Domains, select the authentication domain just created and click Add.

The authentication domain will be moved under Selected.

Click Save to store the change.

Repeat this configuration for all providers (remote and hosted) with which you want to establish trust.

Under Federation, click the Authentication Domains tab.

Select the name of the authentication domain which was previously created.

The General attributes are displayed.

Under Providers, click Add.

The Select Trusted Partner Type and Profile page is displayed.

Select the appropriate provider(s) as trusted members of the authentication domain and click Add.

The provider(s) will be moved under Selected.

Click OK to save the change.

Click Save to store the change.

Trust is now established between the appropriate providers.

Signing Liberty ID-FF Requests and Responses

Federation-based communications passing between identity providers and service providers are generally required to be digitally signed and verified. Signing and verifying messages provides data integrity, data origin authentication, and a basis for non-repudiation. To turn on signing for all Liberty ID-FF requests and responses emanating from your instance of Access Manager, set the value of the com.sun.identity.federation.services.signingOn property in AMConfig.properties to true and restart Access Manager and its web container. This allows for signing of Liberty ID-FF requests being sent and verification of signature validity for Liberty ID-FF responses received. If set to false, signing is disabled. If set to optional, requests and responses will be signed or verified only if required by the federation profile being used. After installation, AMConfig.properties is located in the etc/opt/SUNWam/config directory.

Note –

More information on com.sun.identity.federation.services.signingOn and the other identity federation properties in AMConfig.properties can be found in the Chapter 6, amConfig.properties Reference, in Sun Java System Access Manager 7.1 Administration Reference.

Additionally, you can enable the signing of an authentication request from a service provider configured on your instance of Access Manager, use the following procedure.

To Enable Signing of Service Provider Authentication Requests

Before You Begin

A keystore must be set up before turning on the signing properties. See Appendix B, Key Management information on how to do this.

Select the Federation tab.

Select the Entities tab.

Select the name of the entity that contains the service provider configuration for which you want to enable the signing of an authentication request.

Select Service Provider from the View pull-down menu.

Enable the Sign Authentication Request property under the Service Provider configuration and click Save.

Log out of the Access Manager console.

Dynamic Identity Provider Proxying

An identity provider that is asked to authenticate a principal that has already been authenticated with another identity provider may proxy the authentication request, on behalf of the requesting service provider, to the authenticating identity provider. This is called dynamic identity provider proxying. When the first identity provider receives an authentication request regarding a principal, it prepares a new authentication assertion on its own behalf by referencing the relevant information from the original assertion and sending the assertion to the authenticating identity provider.

Note –

The service provider requesting authentication may control this proxy behavior by setting a list of preferred identity providers or by defining the amount of times the identity provider can proxy the request.

To Configure and Test Dynamic Identity Provider Proxying

The following steps describe the procedure to enable three machines for identity provider proxying and test the configuration. The procedure assumes the three machines have Access Manager installed and are configured as follows:

Machine	Authentication Function	Federation Function
Machine 1	Authenticating Identity Provider	Identity Provider
Machine 2	Proxying Identity Provider	Identity Provider and Service Provider
Machine 3	Requesting Service Provider	Service Provider

All of the WAR files and metadata used in the following procedure can be found in /AccessManager-base/samples/liberty/sample1.

To configure machine 3, deploy the SP1 WAR files and load sp1Metadata.xml.

Ensure that the metadata defines machine 2 as an identity provider and machine 3 as a service provider.

To configure machine 1, deploy the IDP1 WAR files and load idp1Metadata.xml.

Ensure that the metadata defines machine 1 as an identity provider and machine 2 as a service provider.

To configure machine 2, do the following:
1. To configure machine 2 as a service provider, deploy the SP1 WAR files.
  
  Modify AMClient.properties to reflect this.
2. To configure machine 2 as an identity provider, load a second, modified idp1Metadata.xml.
  
  Ensure that idp1Metadata.xml contains only data that defines machine 1 as an identity provider. Remove all other metadata.

Log in to machine 2 and modify the following metadata:
1. Change the value of the Authentication Type attribute to Local.
  
  This attribute can be found in the Access Manager Configuration section of the entity describing machine 2 as a service provider.
2. Add machine 1 and machine 3 to the list of Trusted Providers configured for machine 2.
  
  This attribute can be found in the Trusted Provider section of the entity describing machine 2 as a service provider.
3. Save the configuration.

Also on machine 2, modify the following metadata regarding machine 3.
1. Select the check box next to Enable Proxy Authentication.
  
  This attribute can be found in the Proxy Authentication Configuration section of the entity that defines machine 3 as an identity provider.
2. Add machine 1 to the list of Proxy Identity Providers List.
  
  This attribute can be found in the Proxy Authentication Configuration section of the entity that defines machine 3 as an identity provider. The value is a URI defined as the provider's identifier.
3. Set Maximum Number of Proxies to 1.
4. Save the configuration.

Federate a user between machine 3 (acting as a service provider) and machine 2 (acting as an identity provider).

Federate a user between machine 2 (acting as a service provider) and machine 1 (acting as an identity provider).

Close the browser and attempt single sign-on.

You will be redirected to machine 1 rather than machine 2 if you enter the username and password used to federate with machine 1.