Understanding Typical Business Use Cases

The following are typical use cases for using Policy Agents and the Client SDK to integrate OpenSSO Enterprise with applications in an existing deployment:

• Using Non-Intrusive, Policy Agent-Based Approaches to Web Resources

• Leveraging Fat Clients, Custom Web Applications, and Enterprise JavaBeans

• Complementing Policy Agent Functionality

• Enabling Identity Federation

• Enabling Web Services Security

• Enabling Identity Services

• Coexisting with Non-Sun Deployments

Using Non-Intrusive, Policy Agent-Based Approaches to Web Resources

The following are examples of capabilities that can be leveraged by using the Policy Agents to integrate OpenSSO Enterprise with other applications:

• Pure J2EE applications

  Pure J2EE applications are deployed as WARs installed on J2EE compliant application servers. The resources to be protected include servlets, JavaServer Pages and Enterprise JavaBeans.

• Apache or Sun Web Server-based web applications

  These applications can be HTML pages, multimedia content, and CGIs such as PHP, Perl, JSP, and servlets hosted on the web server.

• .Net /IIS server-based web applications

  These include .Net/ASP or ASPX applications such as Visual Basic and C#, HTML pages and content accessible via the HTTP protocol.

• Enterprise applications

  These include SAP, Siebel, Domino, PeopleSoft, and Portal middleware.

• Proxied applications

  This use case can include all web applications deployed with a reverse proxy server in front of it. No policy agents or added software are required be deployed on the application and its container. A proxy is installed separately from the application, and the policy agent installation also stays separate. Multiple applications can be proxied by the same proxy server, enabling a single agent to protect them all.

Leveraging Fat Clients, Custom Web Applications, and Enterprise JavaBeans

The following are examples of capabilities that can be leveraged by using the Client SDK to integrate OpenSSO Enterprise with other applications:

• Java or C /C++

  Applications can be enabled to directly invoke the Client SDK for authentication, authorization, and auditing services.

• Password Replay

  This use case is for legacy applications that require the user to submit credentials directly to the application before access to services is allowed.

• Application-initiated Authentication

  In this use case, the authentication authority is the application itself. Once the user is authenticated, the remaining security services such as single sign-on, policy evaluation, and identity federation are provided by OpenSSO Enterprise.

Complementing Policy Agent Functionality

In this use case, an OpenSSO Enterprise policy agent is deployed and the Client SDK is embedded in the application or its container. The following are ways in which this configuration helps to complement policy agent functionality:

• Custom service-based access control is automatically in place.

• Policy agents can handle only URL—based policy. The Client SDK can handle various non-URL based policies.

• The Client SDK provides more finely-grained security control that is not possible with policy agents alone.

Enabling Identity Federation

Companies integrate applications with OpenSSO Enterprise to implement identity federation in various ways.

• OpenSSO Enterprise passes attributes from an Identity Provider application to a Service Provider. In this use case, the Identity Provider passes user attribute value pairs to the Service Provider so the Service Provider can provide services to the user based on those attributes.

• OpenSSO Enterprise receives Identity Provider-asserted attributes in a Service Provider application. In this use case the Service Provider verifies the authenticity of the attributes asserted by the Identity Provider. The Service Provider then updates its session with those attributes.

• The OpenSSO Enterprise Fedlet quickly enables federation without having to install a full-featured OpenSSO Enterprise sever at the Service Provider. In this use case, the Service Provider can participate in Federation with an Identity Provider that does have the full-featured OpenSSO Enterprise server installed on it.

Enabling Web Services Security

Companies integrate applications with OpenSSO Enterprise to take advantage of the following OpenSSO Enterprise Web Services Security measures:

• Protecting a web services provider endpoint

• Protecting a web services client invocation

Enabling Identity Services

Applications integrated with OpenSSO Enterprise are able to consume simple OpenSSO Enterprise services in both the SOAP/WSDL style and the REST style. OpenSSO Enterprise may include one or more of the following:

• Authentication

• Authorization of an authenticated identity to access a resource

• Retrieval of an authenticated identity's attributes

• Logging

Coexisting with Non-Sun Deployments

Companies typically integrate OpenSSO Enterprise with non-Sun identity services for two purposes:

• To maintain backward compatibility with legacy applications in an existing environment

  In this use case, legacy non-Sun applications for authentication, authorization, and auditing have already been deployed and will continue to be used in the environment. OpenSSO Enterprise is used primarily to execute federation among both legacy and future applications. OpenSSO Enterprise may also be used for identity services when new applications are added to the environment.

• To facilitate complete migration from the non-Sun identity services to OpenSSO Enterprise

  In this use case, legacy non-Sun applications for authentication, authorization. and auditing have already been deployed. These applications must be maintained until OpenSSO Enterprise can be deployed and tested. Once OpenSSO Enterprise is successfully deployed, the legacy non-Sun identity services are phased out of the environment.