Sun Java System Access Manager Policy Agent 2.2 Guide for Sun Java System Application Server 9.0/Web Services

Sun Java System Access Manager Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services

In general, securing web services involves establishing trust between a WSC and a WSP. For identity-based web services specifically (for example, a calendar service), the WSP would have to trust the WSC to have authenticated the user, or the WSC would have to include the user's credentials as part of the web service request. The distinguishing factor is that identity-based web services authenticate both the WSC and the user's identity. (The user must be authenticated so that the WSC can send the user's token to the WSP in a SOAP security header.)

The Sun Java System Access Manager Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services plugs into Application Server Platform Edition 9.0, provides message level security, and supports both Liberty Alliance Project token profiles as well as Web Services-Interoperability Basic Security Profiles (WS-I BSP). (A profile defines the HTTP exchanges required to transfer XML requests and responses between web service clients and providers.)


Note –

More information on Application Server Platform Edition 9.0 can be found in the collection of documentation provided for the product located at http://docs.sun.com/coll/1343.3.


This release of the agent uses an instance of Access Manager for all authentication decisions. Web services requests and responses are passed to Access Manager authentication modules using standard Java representations based on the transmission protocol. Currently, the Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services provides the following agents:

HTTP Authentication Agent

The HTTP authentication agent protects the endpoints of a web service that uses HTTP for communication. After the HTTP authentication agent is deployed in an instance of Application Server on the WSP side, all HTTP requests for access to web services protected by the agent are redirected to the login and authentication URLs defined in the Access Manager AMConfig.properties file on the WSC side. AMConfig.properties is located in javaee.home/domains/domain_name/config when the Java Platform, Enterprise Edition (Java EE) 5 SDK is installed and in javaee.home/addons/amserver when the Java EE 5 Tools Bundle is installed. The configurable properties are:


Note –

Application Server 9 has the ability to configure only one HTTP agent per instance. Therefore, all authentication requests for all web applications hosted in the container will be forwarded to the one configured agent.


When the WSC makes a request to access a web application protected by an HTTP authentication agent (1 in the illustration below), the agent intercepts the request and redirects it (via the browser) to Access Manager for authentication (2). Upon successful authentication, a response is returned to the application, carrying a token as part of the Java EE Subject (3). This token is used to bootstrap the appropriate Liberty ID-WSF security profile. If the response is successfully authenticated, the request is granted (3).


Note –

For this release, the HTTP authentication agent is used primarily for bootstrapping. Future releases will contain information on how to protect web applications.


The following figure illustrates the interactions described.

HTTP authentication agent protecting HTTP requests
to, and responses from, service providers
Note –

The functionality of the HTTP Provider agent is similar in to that of the Sun Java System Access Manager Java EE agents when used in SSO ONLY mode. This is a non restrictive mode that uses only the Access Manager Authentication Service to authenticate users attempting access. For more information on Java EE agents, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.


SOAP Authentication Agent

The SOAP authentication agent secures SOAP messages between a WSC and a WSP. The agent can be configured for use as an authentication 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 Access Manager and supports the following:


Note –

The configuration process for the SOAP authentication agent is described in Installing the Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services.


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 authentication agent redirects the request to the Access Manager 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 authentication 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 authentication 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 authentication agent on the WSP side, back to the WSC. The SOAP authentication agent on the WSC side then verifies the signature before forwarding the response on to the WSC. The following diagram illustrates the interactions as described.

SOAP authentication agent protecting communications
between clients and service providers

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 web service consumer 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 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 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 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. 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 requests (via the WSC) access to a service. The SOAP authentication agent redirects the request to the Access Manager 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 authentication 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 authentication 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 authentication agent on the WSP side, back to the WSC. The SOAP authentication agent on the WSC side then verifies the signature before forwarding the response on to the WSC. The following diagram illustrates the interactions as described.

Illustration of interactions between WSC and
WSP with deployed SOAP Provider agents 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.