Sun OpenSSO Enterprise 8.0 Administration Guide

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 (referred as Proxying 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. After receiving the Assertion from the authenticating identity provider, the proxying identity provider generates a new Assertion based on the information from the original Assertion, and sends to the requesting service 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.


ProcedureTo 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 OpenSSO Enterprise 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 

  1. Install and configure three OpenSSO instances.

    If those three instances resides on the same domain, you need to modify the cookie name of all three instances to be different from one another. To do so:

    1. Login to administration console and click the Configuration tab.

    2. Click Servers and Sites and choose your server instance.

    3. Click the Security tab, then click Inheritance Settings.

    4. Uncheck the box for the Cookie Name attribute.

    5. Click Save.

    6. Click the Back to Server Profile button.

    7. Modify the value for the Cookie Name attribute under the Cookie section.

    8. Click Save.

    9. Restart the web container on which the server instance is deployed.

  2. Create hosted ID-FF metadata on the requesting service provider instance on machine 3.

    For more information, see ID-FF Entity Provider. When creating the provider:

    1. Enter the service provider entity ID in the Entity Identifier field

    2. Under the Service Provider section, specify meta alias, signing/encryption cert alias if needed.

  3. Export the requesting Service Provider's standard metadata to a XML file. This could be done using the export-entity option in ssoadm CLI or the ssoadm.jsp. The rest of these steps use the file name sp.xml as an example.

  4. Create hosted metadata on the proxying Identity provider instance, o machine 2.

    1. Login to machine 2 as the top-level administrator, click Federation, then click New under Entity Providers table.

    2. Select IDFF in the pop up window

    3. Save the configuration.

    4. Enter the entity ID in the Entity Identifier field.

    5. Under the Identity Provider section, specify a meta alias, and enter signing/encryption cert alias if needed.

    6. Under the Service Provider section, specify a meta alias different from that entered for Identity Provider section, and enter signing/encryption cert alias if needed.

    7. Click create.

  5. Export the proxying identity provider's standard metadata to a XML file. This is done using the export-entity option in ssoadm CLI or ssoadm.jsp. The rest of these steps use the file name proxy.xml as an example.

  6. Create the hosted metadata on the authenticating Identity provider instance, machine 1.

    For more information, see ID-FF Entity Provider. When creating the provider:

    1. Enter the service provider entity ID in the Entity Identifier field

    2. Under the Service Provider section, specify meta alias, signing/encryption cert alias if needed.

  7. Export the authenticating Identity provider's standard metadata to a XML file using the export-entity option in the ssoadm CLI or by using the ssoadm.jsp. The rest of these steps use the file name idp.xml as an example.

  8. Load the remote proxying identity provider metadata on the requesting service provider instance.

    1. Copy the proxy.xml to machine 3.

    2. In the console of machine 3, click the Federation tab and then the Import Entity button.

    3. Choose the realm to which the requesting service provider belongs.

    4. Under Where Does the Meta Data File Reside field, choose File and click Upload.

    5. Choose proxy.xml. The Where Does the Extended Data File Reside can be left blank.

    6. Click Ok.

  9. Create a circle of trust on the requesting service provider instance to include the proxying IDP and requesting SP entity. For information, see Circle of Trust.

  10. Load the remote authenticating identity provider and requesting service provider metadata to the proxying identity provider instance.

    1. Copy the idp.xml and sp.xml files to machine 2.

    2. In the console of machine 2, click the Federation tab and then the Import Entity button.

    3. Choose the realm to which the requesting service provider belongs.

    4. Under Where Does the Meta Data File Reside field, choose File and click Upload.

    5. Choose idp.xml. The Where Does the Extended Data File Reside field can be left blank.

    6. Click OK.

    7. Repeat the steps for loading the requesting service provider meta data (sp.xml).

  11. Create circles of trust on the proxying identity provider instance, machine 2. For information, see Circle of Trust

    Add the requesting service provider and proxying identity provider to the circle of trust. Repeat this step to create a circle of trust for both the authenticating identity provider and the proxying identity provider. Make sure the circles of trust have different names.

  12. Load the remote proxying identity provider metadata on the authenticating identity provider instance, machine 1.

    1. Copy the proxy.xml to machine 1.

    2. In the console of machine 1, click the Federation tab and then the Import Entity button.

    3. Choose the realm to which the requesting service provider belongs.

    4. Under Where Does the Extended Data File Reside field, choose File and click Upload.

    5. Choose proxy.xml. The Where Does the Extended Data File Reside can be left blank.

    6. Click Ok.

  13. Create a create a circle of trust on the authenticating identity provider instance to include the proxying identity provider and authenticating identity provider entities.

  14. Enable Dynamic Identity provider proxying on the requesting service provider instance.

    1. In the console of machine 3, click the Federation tab.

    2. Select the hosted requesting service provider.

    3. Go to Proxy Authentication Configuration.

    4. Check the box for Proxy Authentication to enable it.

    5. Enter 10 for the value in the Maximum Number of Proxies attribute.

    6. Click Save.

  15. Enable dynamic identity provider proxying on the proxying identity provider instance.

    1. In the console of machine 2, click the Federation tab.

    2. Select the hosted proxying identity provider.

    3. Go to Proxy Authentication Configuration.

    4. Check the box for Proxy Authentication to enable it.

    5. Enter 10 for the value in the Maximum Number of Proxies attribute.

    6. Add the authenticating identity provider's entity ID in the Proxy Identity Providers List file.

    7. Click Save.

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

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

  18. Close the browser and attempt to perform a single sign-on again from machine 3. You will be redirected to machine 1 rather than machine 2 for authentication.

    Enter the username and password used on machine 1. You will have a successful single sign-on to machine 3.