Sun OpenSSO identity federation is based on the Liberty Alliance specification which includes uses the Identity Federation Framework (ID-FF) and SAMLv2 protocols. Microsoft Active Directory Federation Service (ADFS) is based on the Web Services Architecture specification which uses the Microsoft Web Browser Federated Sign-On (MS-MWBF) and Web Services Federation (WS-Federation) protocols.
OpenSSO Enterprise provides support for MS-MWBF so that single sign-on can work among OpenSSO and ADFS-based environments. This interoperability is achieved by creating trust relationships between different security realms, and exchanging security tokens using the Web Services Federation protocol.
This chapter provides information about enabling web services federation between ADFS-based and OpenSSO Enterprise. The following topics are contained in this chapter:
This deployment consists of two different environments:
An ADFS-based environment
A load-balanced, multi-server OpenSSO Enterprise environment
This deployment illustrates the interoperability between both environments, and also illustrates the added constraints of a multi-server OpenSSO Enterprise solution.
The ADFS environment is derived entirely from Step-by-Step Guide for Active Directory Federation Services. In this deployment, a web browser (client) interacts with a web resource to request a security token from a requestor Identity Provider or Security Token Service. The request is communicated through a resource partner such as an Identity Provider or Security Token Service.
OpenSSO Enterprise can play the role of either resource (Service Provider) or requestor (Identity Provider). The following figure illustrates OpenSSO Enterprise acting as a Service Provider, known in the MS-MWBF specification as a Resource Identity Provider/Security Token Service (Resource IP/STS). The business use case for this architecture is described in OpenSSO Enterprise Acts as Service Provider.
The following figure illustrates OpenSSO Enterprise acting as an Identity Provider, known in the MS-MWBF specification as a Requestor Identity Provider/Security Token Service (Requestor IP/STS). The business use case for this architecture is described in OpenSSO Enterprise Acts as Identity Provider.
The following are issues you must resolve before you can enable Web Service Federation among ADFS and OpenSSO Enterprise.
The ADFS-based environment is already set up and running.
This chapter is based on the assumption that you are proficient in setting up and ADFS-based environment as described in
OpenSSO Enterprise is already deployed.
This is a prerequisite for configuring OpenSSO Enterprise to act as an Identity Provider or Service Provider in a circle of trust.
The configuration requirements documented in this chapter include tools and procedures that are not appropriate for a production deployment.
Examples are: the use of self-signed certificates, the modification of host files, local time synchronization, and so forth. These are described for illustration purposes only. For production deployments, you must use different solutions suitable for your environment.
OpenSSO Enterprise supports WS-Federation as it relates to its support within the ADFS boundaries. Parts of the WS-Federation specification not required by ADFS may not be supported in this release.
This chapter describes two typical business use cases:
In this use case, Company A is acquired by Company B. The intranets for both companies have been merged, but much of the network infrastructure remains as though they were still two separate entities. Company A maintains an Active Directory domain, and Company B maintains an OpenSSO Enterprise single sign-on infrastructure in its own domain.
In order for Company A employees to access some internal applications available to Company B employees, a trust relationship is created between the Company A domain and the Company B domain. The trust relationship is created using the Web Services Federation protocol. Company A employees, signed on to their Microsoft Windows computers, can now navigate to the Company B paycheck application by using a Web Services Federation secure token.
In this use case, Company B wants to offer its employees a new online collaborative environment based on Microsoft SharePoint Services. The collaboration solutions is an outsourced model where Company C provides dedicated SharePoint Services to its customers. In order to provide single sign-on to the Company B employees, Company C leverages the federation services provided by ADFS. A trust relationship is created between created between the Company B OpenSSO Enterprise Identity Provider and the Company C Resource Identity Provider /Security Token Service.
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.
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.
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.
In the ADFS environment:
Create a new Account Partner using the ADFS snap-in.
The proper name and endpoint URL must be defined.
Import the OpenSSO Enterprise token signing certificate (DER format). For detailed information, see the .Sun OpenSSO Enterprise 8.0 Administration Guide
The following information helps you decide whether enabling Web Services Federation between ADFS and OpenSSO Enterprise is suitable for your needs.
You are likely to leverage WS-Federation in a mixed environment involving Windows domains and heterogeneous web service environments. In such cases, using WS-Federation eliminates the need to complete the complicated setups involved with Desktop SSO (IWA, Kerberos, etc.). This simplifies the integration of web services in the ADFS-based environments.
The immediate benefit is the single sign-on to SharePoint Services from non-ADFs environments. This can be extended to pure claims-based applications residing inside the Resource Partner's domain.
The main drawback to using WS-Federation is that currently only limited support or configuration help is offered for ADFS claims within OpenSSO Enterprise. For example, the Microsoft Administering Active Directory Federation Services Guidehttp://technet.microsoft.com/en-us/library/cc736337.aspx depicts the use of group claims and their mapping between realms. The use of group claims eliminates the need to map user principals information from one realm to the next in a federated environment. These claims, based on group memberships, have not been tested in this deployment example configuration.
Microsoft Web Browser Federated Sign-on Protocol Specification
Web Services Federation Language
Overview of ADFS
Microsoft Administering Active Directory Federation Services Guide
OpenSSO, WS-Federation & IBM DataPower by Joachim Andre