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:

• Authentication at Identity Provider

• Secure Attribute Exchange at the Identity Provider

• Secure Attribute Exchange at the Service Provider

• Global Single Logout

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.