OpenSSO Enterprise creates a comprehensive security and identity management framework optimized to work with, and extend, an identity provider's existing security infrastructure. The following list describes some key features:
Exchange of credentials and security tokens across circle of trust partners for purposes of authentication and single sign-on.
Automatic federation of user accounts across multiple security domains.
Session management across authentication domains to determine when user interactions must be terminated (single logout).
Import or export the data required to establish basic federated communication between providers.
Manages and links providers that are available to participate in a circle of trust.
Exchanges SAML security assertions among providers in a circle of trust.
Data management choices include an LDAPv3 directory (OpenDS, Sun Java System Directory Server or Microsoft Active Directory).
Included service provider interfaces (SPIs) to allow customized logic during the federation process.
Support for bulk federation and auto federation.
Support for The Fedlet, a web archive (WAR) of data that can be embedded into a service provider application.
Support for Virtual Federation.
Support for multiple federation protocols in one circle of trust.
The following sections contain additional information on the final three features listed.
Fedlet is the name given to fedlet.war. The WAR is a very small archive of a few JARs, properties, and metadata (all stored in flat files) that can be embedded into a service provider's Java EE web application to allow for SSO between an identity provider instance of OpenSSO Enterprise and the service provider application - WITHOUT installing OpenSSO Enterprise on the service provider side. The service provider simply downloads the Fedlet, modifies their application to include the Fedlet JARs and, re-archives and redeploys the modified application. The service provider is now able to accept an HTTP POST (that contains a SAML v2 assertion) from the identity provider and retrieve included user attributes to accomplish SSO. (Currently, the Fedlet only supports the HTTP POST Profile.). The Fedlet can communicate with multiple identity providers, using a Discovery Service to find the preferred identity provider. For more information, see the Sun OpenSSO Enterprise 8.0 Administration Guide.
Secure Attribute Exchange (also referred to as Virtual Federation Proxy) provides a mechanism for one application to communicate identity information to a second application in a different domain. In essence, it provides a secure gateway that enables legacy applications to communicate authentication attributes without having to deal specifically with federation protocols and processing. Virtual Federation Proxy allows:
Identity provider applications to push user authentication, profile and transaction information to a local instance of OpenSSO Enterprise which then passes the data to a remote instance of OpenSSO Enterprise at the service provider using federation protocols.
Service provider applications to consume the received information.
Virtual Federation Proxy uses SAML v2 to transfer identity data between the communicating entities. The Client SDK (which contains Java and .NET interfaces) runs independent of OpenSSO Enterprise and enables existing applications to handle the SAML v2 interactions. The following diagram illustrates this scenario.
The following use cases are applicable to Virtual Federation:
When a user is already authenticated within 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 verifies the authenticity of the message and establishes a session for the authenticated user. You can use Virtual Federation to transfer the user's authentication information to the local instance of OpenSSO Enterprise in order to create the session.
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 of OpenSSO Enterprise asserting the user's identity, and containing a set of attribute/value pairs related to the user (for example, data from the persistent store representing certain transactional states in the application). OpenSSO Enterprise verifies the authenticity of the message, establishes a session for the authenticated user, and populates the session with the user attributes.
When a user is already authenticated by the instance of OpenSSO Enterprise at the identity provider and invokes an identity provider application that calls for redirection to a service provider, the identity provider invokes one of the previous use cases and encodes a SAML v2 SSO URL as a part of the request. The identity provider instance of OpenSSO Enterprise then initiates SAML v2 SSO with the instance of OpenSSO Enterprise at the service provider. The service provider's instance of OpenSSO Enterprise then verifies the SAML v2 assertion and included attributes, and redirects to the service provider application, securely transferring the user attributes via a secure HTTP POST message. The service provider application consumes the attributes, establishes a session, and offers the service to the user.
When a user is already authenticated and has established, for example, SSO with the instance of OpenSSO Enterprise at the service provider, the user might click on a Global Logout link. The identity provider will then invalidate its local session (if created) and trigger SAML v2 single log out by invoking a provided OpenSSO Enterprise URL. The OpenSSO Enterprise identity provider executes the SAML v2 single log out, terminating the session on both provider instances of OpenSSO Enterprise.
An identity provider side application can initiate single logout by sending sun.cmd=logout attributes via a Virtual Federation interaction to a local instance of OpenSSO Enterprise acting as the identity provider. In turn, this instance will execute SAML v2 single logout based on the current session.
For more information, see the Sun OpenSSO Enterprise 8.0 Administration Guide.
OpenSSO Enterprise allows a configured circle of trust to contain entities speaking different federation protocols thus supporting cross protocol single sign-on and logout among hosted identity providers in the same circle of trust. For example, you can create a circle of trust containing one identity provider instance that communicates with multiple federation protocol and three service provider instances that speak, respectively, Liberty ID-FF, SAML v2 and WS-Federation. Figure 10–2 illustrates the process of multi-federation protocol single sign-on and single logout.
For more information, see the Sun OpenSSO Enterprise 8.0 Administration Guide.