Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Chapter 6 Implementing a Virtual Federation Proxy (Secure Attributes Exchange)

Secure Attributes Exchange, also known as Virtual Federation Proxy, is a new feature in Sun OpenSSO Enterprise 8.0. Secure Attributes Exchange provides the means for an application to securely transfer identity information to another application located in a different domain. Secure Attributes Exchange enables legacy applications to leverage standards-based federation to communicate with other existing applications and services without having to set up and configure federation protocols and processes for each application.

This chapter provides information to help you determine whether Secure Attributes Exchange is appropriate for your environment. The following topics are contained in this chapter:

About Virtual Federation Proxy (Secure Attributes Exchange)

Multiple authentication systems often exist in typical legacy environments. Although these authentication systems would work more efficiently if they were federated, implementing single sign-on often requires deploying one federation software instance for each of the authentication systems in the environment (see the following figure). The complexities of such deployments usually impose additional constraints in selecting federation solutions, and impede any progress toward enabling federation among the many authentication systems.

Figure 6–1 Multiple Authentication Systems in a Legacy Environment

Multiple authentication systems with a separate
federation software per each authentication system.

SAMLv2 and other federation protocols may provide quick, standards-based federation enablement. But legacy identity systems on the enterprise end and existing Identity Provider applications cannot pass user authentication, user profile, and other transaction related data to the local Identity Provider instance. Similarly, the existing framework also limits the ways in which Service Provider applications consume user authentication, profile, and transaction information.

The Secure Attributes Exchange feature introduced in OpenSSO Enterprise 8.0 is designed to meet these business needs. OpenSSO Enterprise enables an OpenSSO Enterprise instance in either the Identity Provider role or in the Service Provider role to act like a pure SAMLv2 protocol gateway. Simple, default security mechanisms are implemented to allow a loose coupling between the existing applications and OpenSSO Enterprise instances. The following figure illustrates how a streamlined solution enables federation among multiple legacy authorization systems with a centralized configuration.

Figure 6–2 Multiple Authentication Systems Using Secure Attributes Exchange

Secure Attributes Exchange takes the place of
multiple federation applications.

A Secure Attributes Exchange interaction enables the following:

Identity Provider applications push user authentication, user profile, and transaction information to a local instance of OpenSSO Enterprise. The local instance of OpenSSO Enterprise, using federation protocols, passes the data to a remote instance of OpenSSO Enterprise at the Service Provider.
Service Provider applications consume the received information in a secure manner.

In this first offering of Secure Attributes Exchange, only OASIS SAMLv2 protocol is supported. However, the solution can be extended in the future to be completely protocol-neutral so that other single sign-on protocols such as Liberty ID-FF and WS-Federation can also be supported.

Analyzing the Deployment

Secure Attributes Exchange uses the SAMLv2 protocol to transfer identity data between the communicating entities. The Secure Attributes Exchange client APIs, including both Java and .NET interfaces, run independently of the OpenSSO Enterprise instance. The Secure Attributes Exchange client APIs enable existing applications to handle the SAMLv2 interactions.

The following figure illustrates the deployment architecture for Secure Attributes Exchange.

Figure 6–3 Deployment Architecture for Secure Attributes Exchange

Identity Provider and Service Provider communicate
through SAMLv2 and Single Sign-On protocols.

In this Secure Attributes Exchange example:

Secure Attributes Exchange acts as a pure SAMLv2 protocol gateway, relying entirely on the existing applications for user authentication and retrieval of the user profile attributes.
From the perspective of Identity Provider applications and Service Provider applications, Secure Attributes Exchange implements a push-model solution to securely transfer authentication and attributes data.
Secure Attributes Exchange uses simple HTTP GET/POST and data signing and encryption to securely transfer authentication and attributes data from and to legacy applications.
Secure Attributes Exchange supports both symmetric-key and asymmetric-key based cryptography to secure authentication and attributes data
Secure Attributes Exchange supports application-initiated single sign-on and single logout.

The figures Figure 6–4 and Figure 6–5 illustrate the process flow in a typical Secure Attributes Exchange interaction. In this example, bank employees each have a user account in a bank's employee identity system. Employees routinely access an internal application that validates bank customers' personal checks. The bank employees are required to authenticate themselves before accessing the Cheque Validation application. Validating checks involves retrieving the check images which are stored and processed by the Cheque Image application. The Cheque Image application which is hosted by a business partner at a remote site. User identity and attribute data must be supplied by the local Cheque Validation application and passed to the remote Cheque Image application in a secure manner.

Figure 6–4 Process Flow for Secure Attributes Exchange (Continued on next page)

Text-based, needs no further explanation.

Figure 6–5 Process Flow for Secure Attributes Exchange (Continued)

Considering Assumptions, Dependencies, and Constraints

Before you can implement Secure Attributes Exchange, you must consider the following assumptions and constraints.

Assumptions

The implementation will automatically use the authn=Force functionality to allow Identity Provider applications to repeatedly invoke the secure attribute transfer feature.
The mappings between the Service Provider application URL prefix to the Service Provider id have been explicitly defined in the product configuration.
Local Service Provider single logout functionality relies on OpenSSO Enterprise be able to redirect to an external URL during SAMLv2 single logout processing, and then resume the original SAMLv2 single logout when redirected back.
Cryptography APIs are assumed to be available on all targeted platforms and programming languages.

Constraints

The scope of the current OpenSSO Enterprise implementation is limited to SAMLv2–based single sign-on only. However, it is possible for you to extend this to other single sign-on protocols such as the Liberty Identity Federation Framework (ID-FF) and Web Service Federation (WS-F) specifications.
The existing implementation supports only simple HTTP GET and POST based mechanisms. However, you should be able to use the same APIs to do XML-based attribute transfer as well.
Integration with specific proprietary application server technologies such as WebSphere LTPA and WebLogic for single sign-on as well as single logout are not addressed in this document.
Limited single logout functionality is implemented. Logout from multiple Identity Provider applications and multiple Service Provider applications is not directly addressed in this document. The Identity Provider and Service Provider must implement logout appropriately to meet their own needs.

Secure Attributes Exchange Client APIs

The Secure Attributes Exchange feature provides a set of client APIs in both Java and .NET interfaces. the client APIs are used to enable following:

Identity Provider applications push user authentication, user profile, and transaction related information to the local OpenSSO Enterprise instance. The information is then passed over to the Service Provider side using the federation protocols,
Service Provider applications consume the same user profile and transaction information.

The details of Secure Attributes Exchange client APIs are described in detail in the Sun OpenSSO Enterprise 8.0 Java API Reference .

Understanding Typical Business Use Cases

Secure Attributes Exchange is used by three types of users:

Developers

As application owners, developers use the Secure Attributes Exchange client APIs to connect to a local OpenSSO Enterprise instance.
Administrators

Administrators are responsible for configuring Secure Attributes Exchange, setting up and maintaining provision keys, configuring authorization of each application, and so forth.
End users

End users access the deployed applications.

The figures Figure 6–4 and Figure 6–5 illustrate a typical process flow for Secure Attributes Exchange.

The process flow can be described as the sum of four separate uses cases:

It is not absolutely required for service providers to implement the Secure Attributes Exchange functionality. This is certainly a valid business use case as long as the receiving end is a SAMLv2 compliant Service Provider that is capable of using the information originating from the Identity Provider application and sent by the Identity Provider.

Authentication at Identity Provider

When a user is already authenticated in an enterprise, the legacy identity provider application sends a secure HTTP GET/POST message to OpenSSO Enterprise asserting the identity of the user. OpenSSO Enterprise then verifies the authenticity of the message and establishes a session for the authenticated user. Secure Attributes Exchange can be used to transfer the user's authentication information to the local instance of OpenSSO Enterprise in order to create a new session.

Secure Attribute Exchange at the Identity Provider

When a user is already authenticated by, and attempts access to, a legacy identity provider application, the legacy application sends a secure HTTP POST message to the local instance ofOpenSSO Enterprise. The HTTP POST message asserts the user's identity and contains a set of attribute-value pairs related to the user. For example, the attribute-value pairs may contain data from the persistent store, and the data may represent certain transactional states in the application. OpenSSO Enterprise verifies the authenticity of the message, establishes a session for the authenticated user, and then populates the session with the user attributes.

Secure Attribute Exchange at the Service Provider

When a user is already authenticated by the instance of OpenSSO Enterprise at the Identity Provider, and OpenSSO Enterprise invokes an Identity Provider application that calls for redirection to a Service Provider, the Identity Provider invokes secure attribute exchange at either the Service Provider or Identity Provider as described above. OpenSSO Enterprise encodes a SAMLv2 single sign-on URL as a part of the request. The Identity Provider instance of OpenSSO Enterprise then initiates SAMLv2 single sign-on with the instance of OpenSSO Enterprise at the Service Provider. The Service Provider instance of OpenSSO Enterprise then verifies the SAMLv2 assertion and the included attributes, and redirects to the Service Provider application. The user attributes are securely transferred using a secure HTTP POST message. The Service Provider application consumes the attributes, establishes a session, and then offers the service to the user.

Global Single Logout

Global single logout can be implemented in various ways. In this example, a user is already authenticated and has established single sign-on with the Service Provider instance of OpenSSO Enterprise. The user clicks on a Global Logout link. The Identity Provider will then invalidate its local session, if it's already created, and trigger SAMLv2 single logout by invoking a provided OpenSSO Enterprise URL. The OpenSSO Enterprise Identity Provider executes the SAMLv2 single logout, terminating the session on both Identity Provider and Service Provider instances of OpenSSO Enterprise.

Setting Up and Configuring Secure Attributes Exchange

Before configuring and using the Secure Attributes Exchange, administrators must make some decisions regarding security-related settings such as cryptography type, applicable keys, and application identifiers. Administrators must be familiar with basic SAMLv2 concepts and the SAMLv2 samples bundled with OpenSSO Enterprise.

This section provides a high-level summary you need to resolve before configuring Secure Attributes Exchange.

About Cryptography Type

Secure Attributes Exchange provides symmetric and asymmetric cryptography types to secure identity attributes between an instance of OpenSSO Enterprise and an application.

Symmetric cryptography

Involves the use of a shared secret key known only to the participants in the communication. The key is agreed upon beforehand and is used to encrypt and decrypt the message.
Asymmetric cryptography

Uses two separate keys for encryption and the corresponding decryption - one public key and one private key. The information is encrypted with a public key known to all, and then decrypted by the recipient only, using a private key to which no one else has access.

This process is known as a public key infrastructure (PKI). On the Identity Provider side, the public key must be added to the OpenSSO Enterprise keystore. The private key must be stored in a protected keystore such as a Hardware Security Module (HSM) for access by the Identity Provider application. On the Service Provider side, the private key must be added to the OpenSSO Enterprise keystore, and the public key stored in a keystore that is local to the Service Provider application.

Overview of Setup Steps

Establish trust among the application or multiple applications and the instance of OpenSSO Enterprise on the Identity Provider. This includes the configuring the cryptography type, applicable keys, and application identifiers.
Establish trust among the application or multiple applications and the instance of OpenSSO Enterprise on the Service Provider side. This includes configuring the cryptography type, applicable keys, and application identifiers.
(Optional) The following steps are specific to using SAMLv2 with auto-federation.
1. Determine which identity attributes you want transferred as part of the SAMLv2 single sign-on interaction.
2. Determine which attribute you will use to identify the user on the Service Provider side.
Determine which URL on the Service Provider will be responsible for handling logout requests from the Identity Provider.

Configuring Secure Attributes Exchange

Secure Attributes Exchange configuration involves modifying two different OpenSSO Enterprise installations: one OpenSSO Enterprise instance on the Identity Provider side, and one OpenSSO Enterprise instance on the Service Provider side. Before proceeding with the instructions in this chapter, you must download and deploy the OpenSSO Enterprise WAR file to a supported web container.

A SAMLv2 provider with Secure Attributes Exchange can be configured by using one of the following alternatives:

In the administration console, use the OpenSSO Enterprise Common Tasks interface to configure SAML configuration and to configure Secure Attribute Exchange.
Import the metadata using the command-line interface.

About the Software Binaries

The software binaries for Secure Attributes Exchange in OpenSSO Enterprise are included in the following components. Locations are relative within the opensso_enterprise_80.zip file.

Deployable opensso.war

The OpenSSO Enterprise server
libraries/jars/openssoclientsdk.jar

For client applications using Java APIs
libraries/dll/famsae.dll

For client applications using .NET APIs

High-level Configuration Steps

For detailed instructions for configuring Secure Attributes Exchange, see the Administration Guide. For deployment planning purposes, the following provides a high-level overview of steps to configure Secure Attributes Exchange:

Configure the instance of OpenSSO Enterprise on the Identity Provider side for the hosted Identity Provider.
1. Set up trust between the Identity Provider application and the OpenSSO Enterprise Identity Provider instance.
  
  Determine and configure the cryptography type, applicable keys, and application identifiers.
2. Determine the Identity Provider application name.
3. Determine the Identity Provider Secure Attributes Exchange handler URL.
4. Set up attribute mapping.
Configure the instance of OpenSSO Enterprise on the Identity Provider side for the remote Service Provider.
1. Set up the attribute mapping.
2. Determine the Service Provider Virtual Federation handler URL.
Configure the instance of OpenSSO Enterprise on the Service Provider side for the hosted Service Provider.
1. Set up trust between Service Provider application and OpenSSO Enterprise Service Provider instance.
  
  Determine and configure the cryptography type, applicable keys, and application identifiers.
2. Turn on auto-federation and specify the attribute that will identify the user's identity
3. Determine the Service Provider Application URL.
4. Set up attribute mapping.
5. Determine the Service Provider logout URL.

Evaluating Benefits and Tradeoffs

Most enterprises today have to deal with various legacy applications and identity systems. It is challenging to make any major infrastructure change simply to accommodate identity federation.

Benefits

Secure Attributes Exchange allows businesses to quickly implement standards-based federation without having to invest in expensive tooling to bridge incompatibilities.
The Secure Attributes Exchange feature provides a very simple mechanism that enables an application to communicate identity information with a partner application in two different domains. Communication can take place within a circle of trust using the SAMLv2 protocol. This functionality can be extended to support other federation specifications as well.
The Secure Attributes Exchange is a major step forward in the direction of identity federation enabling the legacy systems. Secure Attributes Exchange provides integration points, adapters and deployment guidance that can help facilitate the adoption of federation solutions.

Tradeoffs

Although the Secure Attributes Exchange feature in OpenSSO Enterprise makes it easier to implement identity federation among legacy applications, a SAMLv2–compliant Service Provider must already be in place. The Service Provider can be OpenSSO Enterprise or any other vendor solution. But even a small Service Provider requires an identity federation-aware software infrastructure in order to make use of Secure Attributes Exchange.

An alternative to Secure Attributes Exchange is to enable identity federation using the OpenSSO Enterprise Fedlet. The Fedlet is a streamlined Service Provider implementation used to quickly and simply enable identity federation. The Fedlet does not require the installation of any other identity federation software components such as the OpenSSO Enterprise server. For more information about the Fedlet, see Chapter 5, Using the OpenSSO Enterprise Fedlet to Enable Identity Federation