About the OpenSSO Enterprise Fedlet

The OpenSSO Enterprise Fedlet is compliant with SAMLv2 standards so you can embed the Fedlet in a J2EE web application. You can embed the Fedlet SDK into a Service Provider application, and enable the application to accept SAML POSTs from an Identity Provider. The application can then use the Fedlet SDK to pull user attributes into the Service Provider application. The user attributes become part of the SAML Response from the Identity Provider. After the user has successfully authenticated to the Identity Provider, the Identity Provider sends the SAML Response to the Fedlet .

The following figures illustrates how OpenSSO Enterprise, as the Identity Provider, determines which user attributes to include in the SAMLv2 Response to the Service Provider.

Figure 5–1 OpenSSO Enterprise Determines Which User Attributes to Include in the SAML Response

Using The Fedlet with Multiple Identity Providers

You can install multiple Fedlet instances at the Service Provider so that each Fedlet instance talks to a different Identity Provider. Or you can deploy a single OpenSSO Enterprise instance at the Service Provider.

If you want to install multiple Fedlet instances so that each Fedlet instance talks to a different Identity Provider, use caution with this approach. Consider the following example. A ringtone provider acts as a Service Provider and conducts business with multiple telecommunications companies. Each telecommunications company acts as its own Identity Provider. The Service Provider might have to deploy multiple instances of its Ringtone Application, each with its own Fedlet instance. Each Fedlet instance would communicate with a different telecommunications company Identity Provider. The result is that each Identity Provider would be using a different instance of the Ringtone Application.

Consider another example. The Fedlet is deployed on Sun Application Server, and the Fedlet home-directory is configured in the Application Server domain configuration file, domain.xml. So for each new Fedlet instance, a new Application Server domain must be set up, and an instance of the Ringtone Application must be deployed on this new Application Server domain. Now the Service Provider has to maintain two Application Server domains for the same Ringtone Application. This presents two possibilities. One possibility is that the same Ringtone Application is run on different ports for different Identity Providers. The second possibility is that the same Ringtone Application is run on the same port on different machines. This could also translate into different Ringtone Application URLs that each Identity Provider will use with the Service Provider. Or the Service Provider would have to implement some logic to route to the correct Ringtone Application based on the particular Identity Provider requesting it.

Using an Identity Provider Discovery Service with Multiple Identity Providers

The Fedlet supports multiple Identity Providers. Additionally, the Fedlet supports the use of a separate Identity Provider Discovery Service to allow the user to select a preferred Identity Provider to authenticate against. When configured this way, the Identity Provider Discovery Service will remember the user's preferred Identity Provider, and communicate this to the Fedlet. The Fedlet will then be able to determine which Identity Provider to have the user authenticate to. You can deploy an OpenSSO Enterprise instance as an Identity Provider Discovery Service. However, the Fedlet can work with any Identity Provider Discovery Service. The figure below illustrates the process flow in a Fedlet deployment when the Identity Provider Discovery Service is used to set the user's preferred Identity Provider.

Figure 5–2 Identity Provider Discover Services is Set to User's Preferred Identity Provider

The following figure illustrates the process flow in a Fedlet deployment when the Identity Provider Discovery Service is used to retrieve the user's preferred Identity Provider.

Figure 5–3 Identity Provider Discovery Service Retrieves the User's Preferred Identity Provider