About Web Services Security with OpenSSO Enterprise

Web services are accessed by sending SOAP messages to service endpoints identified by URIs, and receiving SOAP message responses. Towards this end, OpenSSO Enterprise has implemented a Security Token Service and agents to enforce security. This architecture is illustrated below.

Figure 11–1 Web Services Security Architecture in OpenSSO Enterprise

The top half of the diagram illustrates a typical web services communication with the addition of agents (WS-Security Provider Plug-in) to enforce message level security and a security token service to issue security tokens. The bottom half represents OpenSSO Enterprise and the interfaces that are called by the WSC and WSP to accomplish web services security. The agents provide access to OpenSSO Enterprise (using the Client SDK) to secure and validate the SOAP requests and responses.

When using web services security, the outgoing web service messages and the incoming web service calls must be authenticated and authorized. Towards this end, the messages must be modified to add headers containing credentials for those purposes. Additional identity attributes (for example, the roles and memberships) can also be added and used by the web service provider's agent and/or by the web service's business logic to provide appropriate service. The authentication and authorization by the agent at the web service provider would leverage the OpenSSO Enterprise Authentication Service and Policy Service. For authentication, it extracts the authentication credentials from the web service request and calls the appropriate authentication module for validation. For authorization, the web service's endpoint port and the operation being performed is the resource for the defined policy.

Security agents are deployed on both the WSC side and the WSP side of the communication. OpenSSO Enterprise contains interfaces with which the agents (deployed remotely to the server) can communicate. The WSC which makes the web service call provides support for securing outgoing communications and validating incoming responses from the WSP. There are two kinds of interfaces used by the WSC, one for administration and another used at run time for securing and validating requests and responses. The WSP which provides service based on calls from the WSC provides support for validating incoming requests and secure outgoing responses. Similar to the WSC, the WSP has an administration interface and an interface used at run time for securing and validating requests and responses. There are also administrative interfaces to configure (local to OpenSSO Enterprise) the Security Token Service and the respective security mechanisms supported by the WSC and WSP. These configurations are stored in the OpenSSO Enterprise configuration data store.

The following diagram illustrates support for web services security in OpenSSO Enterprise. The Security Token Service is supported with any party that understands the WS-Trust specification on which it is based. On the WSC side, an agent developed using the JSR-196 specification is supported on Glassfish (Sun Application Server). (Currently there are no other WSC supported agents although custom handlers and filters can be developed.) On the WSP, the same JSR-196 agent is supported on the Glassfish (Sun Application Server) while Sun policy agents 3.0 are supported on WebLogic, WebSphere and Tomcat.

Figure 11–2 Web Services Security Support in OpenSSO Enterprise

See The Security Token Service and Security Agents for more information.