Security Agents

Security agents (or web service security providers based on the JSR-196 specification) provide message level security, and support Liberty Alliance Project security tokens, Web Services-Interoperability Basic Security Profiles (WS-I BSP) tokens, and proprietary OpenSSO Enterprise session tokens. The agents use an instance of OpenSSO Enterprise for agent configuration data storage as well as authentication decisions. Web services requests and responses are passed to the appropriate authentication module using standard Java representations based on the transmission protocol. The following security agents are currently supported.

• HTTP Security Agent

• SOAP Security Agent

In previous Sun documentation, this agent was referred to as an authentication agent.

HTTP Security Agent

The HTTP security agent protects the endpoints of a web service that uses HTTP for communication. After the HTTP agent is deployed in a web container on the WSP side, all HTTP requests for access to web services protected by it are redirected to the login and authentication URLs defined in the OpenSSO Enterprise configuration data on the WSC side. The configurable properties are:

• com.sun.identity.loginurl=ossoserver_protocol://ossoserver_host:ossoserver_port/ossoserver/UI/Login

• com.sun.identity.liberty.authnsvc.url=ossoserver_protocol://ossoserver_host:ossoserver_port/ossoserver/Liberty/authnsvc

For this release, the HTTP security agents are used primarily for bootstrapping. Future releases will protect web applications.

Figure 14–7 illustrates the interactions described in the procedure below it.

Figure 14–7 HTTP Security Agent Process

1. A WSC (user with a browser) makes a request to access a web service protected by an HTTP security agent.

2. The security agent intercepts the request and redirects it (via the browser) to OpenSSO Enterprise for authentication.

3. Upon successful authentication, a response is returned to the web service, carrying a token as part of the Java EE Subject.

   This token is used to bootstrap the appropriate Liberty ID-WSF security profile. If the response is successfully authenticated, the request is granted.

The functionality of the HTTP security agent is similar to that of the Java EE policy agent when used in SSO ONLY mode. This is a non restrictive mode that uses only the OpenSSO Enterprise Authentication Service to authenticate users attempting access. For more information on Java EE policy agents, see the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents.

SOAP Security Agent

The SOAP security agent secures SOAP messages between a WSC and a WSP. It can be configured for use as a security provider on either the WSC server or the WSP server. This initial release encapsulates the Liberty Identity Web Services Framework (Liberty ID-WSF) SOAP Binding Specification (as implemented by OpenSSO Enterprise) and supports the following tokens.

• Supported Liberty Alliance Project Security Tokens

• Supported Web Services-Interoperability Basic Security Profile Security Tokens

Supported Liberty Alliance Project Security Tokens

In a scenario where security is enabled using Liberty Alliance Project tokens, the HTTP client requests (via the WSC) access to a service. The HTTP security agent redirects the request to the OpenSSO Enterprise Authentication Service for authentication and to determine the security mechanism registered by the WSP and obtain the security tokens expected. After a successful authentication, the WSC provides a SOAP body while the SOAP security agent on the WSC side inserts the security header and a token. The message is then signed before the request is sent to the WSP.

When received by the SOAP security agent on the WSP side, the signature and security token in the SOAP request are verified before forwarding the request on to the WSP itself. The WSP then processes it and returns a response, signed by the SOAP security agent on the WSP side, back to the WSC. The SOAP security agent on the WSC side then verifies the signature before forwarding the response on to the WSC. Figure 14–8 illustrates these interactions.

Figure 14–8 SOAP Security Agent Process for Liberty Alliance Project Security Tokens

The following Liberty Alliance Project security tokens are supported in this release:

X.509

A secure web service uses a PKI (public key infrastructure) in which the WSC supplies a public key as the means for identifying the requester and accomplishing authentication with the web service provider. Authentication with the web service provider using processing rules defined by the Liberty Alliance Project.

BearerToken

A secure web service uses the Security Assertion Markup Language (SAML) SAML Bearer token confirmation method. The WSC supplies a SAML assertion with public key information as the means for authenticating the requester to the web service provider. A second signature binds the assertion to the SOAP message This is accomplished using processing rules defined by the Liberty Alliance Project

SAMLToken

A secure web service uses the SAML holder-of-key confirmation method. The WSC adds a SAML assertion and a digital signature to a SOAP header. A sender certificate or public key is also provided with the signature. This is accomplished using processing rules defined by the Liberty Alliance Project.

Supported Web Services-Interoperability Basic Security Profile Security Tokens

In a scenario where security is enabled using Web Services-Interoperability Basic Security Profile (WS-I BSP) tokens, the HTTP client (browser) requests (via the WSC) access to a service. The SOAP security agent redirects the request to the OpenSSO Enterprise Authentication Service for authentication and to determine the security mechanism registered by the WSP and obtain the expected security tokens. After a successful authentication, the WSC provides a SOAP body while the SOAP security agent on the WSC side inserts the security header and a token. The message is then signed before the request is sent to the WSP.

When received by the SOAP security agent on the WSP side, the signature and security token in the SOAP request are verified before forwarding the request on to the WSP itself. The WSP then processes it and returns a response, signed by the SOAP security agent on the WSP side, back to the WSC. The SOAP security agent on the WSC side then verifies the signature before forwarding the response on to the WSC. Figure 14–9 illustrates the interactions as described.

Figure 14–9 SOAP Provider Agent Process for WS-I BSP Security Tokens

The following WS-I BSP security tokens are supported in this release.

User Name

A secure web service requires a user name, password and, optionally, a signed the request. The web service consumer supplies a username token as the means for identifying the requester and a password, shared secret, or password equivalent to authenticate the identity to the web service provider.

X.509

A secure web service uses a PKI (public key infrastructure) in which the web service consumer supplies a public key as the means for identifying the requester and accomplishing authentication with to the web service provider.

SAML-Holder-Of-Key

A secure web service uses the SAML holder-of-key confirmation method. The web service consumer supplies a SAML assertion with public key information as the means for authenticating the requester to the web service provider. A second signature binds the assertion to the SOAP payload.

SAML-SenderVouches

A secure web service uses the SAML sender-vouches confirmation method. The web service consumer adds a SAML assertion and a digital signature to a SOAP header. A sender certificate or public key is also provided with the signature.