How Virtual Federation Proxy Works

The components of a secure attribute exchange are listed and illustrated below.

• Legacy identity provider application (blue IDP)

• Service provider application (blue SP)

• Independent instances of OpenSSO on both the identity provider and the service provider sides (green)

• A user agent

Figure 8–1 A Secure Attribute Exchange Using SAML v2

The following graphic illustrates the process behind a secure attribute exchange interaction. Details are below the illustration.

1. A user authenticates.

   This may be done by the identity provider application or it may be delegated to an authentication authority.

2. The authenticated user uses the identity provider application and, at some point, accesses a link representing a service provided by an application in a different domain.

3. The identity provider application assembles the appropriate user attributes (authentication and user profile data), encodes and signs it using the API, and posts the secure data to the local instance of OpenSSO Enterprise.

   The com.sun.identity.sae.api.SecureAttrs class is provided by OpenSSO Enterprise and carries the user identifier and the service provider destination.

4. The SAE authentication module on the instance of OpenSSO Enterprise local to the identity provider verifies the authenticity of the attributes also using the SAE API, and initiates the appropriate SAML v2 single sign-on protocol to send the attributes to the instance of OpenSSO Enterprise local to the service provider being accessed.

5. The instance of OpenSSO Enterprise local to the service provider secures the user attributes, and sends them to the service provider application.

   The service provider application uses interfaces supplied by OpenSSO Enterprise to verify the authenticity of the attributes.

6. The service provider application provides or denies the service to the user based on the attributes received.

It is not mandatory for the service provider end of the process to implement VFP. Since the attributes are carried in a SAML v2 assertion, the service provider could choose another way to invoke the requested application. For example, the service provider can use standard SAML v2 protocols to invoke a SAML v2-compliant service provider that does not implement SAE. The RelayState element as defined in the SAML v2 specification can be used to redirect to the local service provider application.