Setting up and Configuring Single Sign-On
Among OpenSSO Enterprise and ADFS Environments

This chapter provides high-level deployment information for
setting up and configuring single sign-on among OpenSSO Enterprise
and ADFS environments. For detailed information, see the Microsoft
Administering Active Directory Federation Services Guidehttp://technet.microsoft.com/en-us/library/cc736337.aspx for
instructions on configuring Resource and Account Partners. See the Sun OpenSSO Enterprise 8.0 Administration Guide for information about using
the ssoadmin command or administration console
to generate metadata, create a circle of trust and import entities.

Enabling WS-Federation between an ADFS environment and an OpenSSO Enterprise environment
involves exchanging metadata to enable a trust relationship. Prior
to this, the following requirements must be met:

All communications between WS-Federation components
must be made over SSL.

ADFS does not perform an HTTP
POST of a WS-Federation RSTR to a non-HTTPS URL.

Name resolution is based on host files. Therefore,
host files must be appropriately updated with host names and IP addresses.

The ADFS environment can rely on DNS.

All servers must be time-synchronized.

This
is essential to proper token validation.

Token signing certificates must be created and imported
for both ADFS and OpenSSO Enterprise endpoints.

This process
is automated in ADFS, but requires the use of the keytool command
for OpenSSO Enterprise.

The creation of a trust relationship relies on the exchange
of metadata between the parties involved. Importing this information
is straightforward and can be done through the GUI on the ADFS side.
On the OpenSSO Enterprise side, to import the information you can use the ssoadmin command-line utility or the ssoadmin.jsp.

Configuring OpenSSO Enterprise to Act as
a Service Provider

This use case requires that the ADFS server in the Company B
domain be configured to recognize the Company A OpenSSO Enterprise
endpoint as a Resource Partner. The Company B ADFS server must be
recognized as a valid Identity Provider in a circle of trust that
includes the Company A OpenSSO Enterprise server as a Service Provider.

In the OpenSSO Enterprise environment:

Use the ADFS snap-in to create a new Resource Partner. The new
Resource Partner must be defined using the proper name and endpoint
URL.

In the ADFS-based environment:

Create metatdata and extended metadata files to define
the Company B ADFS server as the Identity Provider, and the Company
A OpenSSO Enterprise server as the Service Provider in a WS-Federation
protocol paradigm.

Create a new circle of trust and import each Identity
Provider and Service Provider to belong to this circle of trust.

This configuration currently works only if a user account with
the same UPN is created in both the ADFS domain and the OpenSSO Enterprise server.
This is a major constraint.

Configuring OpenSSO Enterprise to Act as
an Identity Provider

This use case requires that the ADFS server in the Company C
domain to be configured to recognize the Company A server as an Account
Partner. The Company A server must be configured to recognize the
Company C ADFS server as a Service Provider in a circle of trust.

In the OpenSSO Enterprise environment:

Configure a new keystore for the token signing certificate,
or leverage the one provided by the container.

Create metadata and extended metadata files to define
the Company A OpenSSO Enterprise server as the Identity Provider.

Create metadata and extended metadata files to define
the Company B ADFS server as the Identity Provider, and the Company
C ADFS server as the Resource Provider in a WS-Federation protocol
paradigm.

Create a new circle of trust, and import each Identity
Provider and Service Provider to belong to this new circle of trust.