Message security responsibilities are assigned to the following:
The application developer can turn on message security, but is not responsible for doing so. Message security can be set up by the System Administrator so that all web services are secured, or set up by the Application Deployer when the Application Server provider configuration is insufficient.
The application developer or assembler is responsible for the following:
The application deployer is responsible for:
These security tasks are discussed in the Securing Applications chapter of the Developers’ Guide. For a link to this chapter, see "Further Information".
The system administrator is responsible for:
A system administrator uses the Admin Console to manage server security settings and keytool
to manage certificates. This document is intended primarily for system administrators. For an overview of message security tasks, see "Configuring the Application Server for Message Security".
WSS defines the binding of XML digital signatures, XML encryption, and username/password tokens to secure SOAP messages. WSS in the Application Server defines how to use WSS to secure invocations of web services, including web services deployed on our Application Server.
The WSS specification provides an extensible mechanism for associating security tokens with SOAP messages. The WSS specification itself does not define the format of the various types of security tokens. Instead, a series of security token profile documents have either been published or are in the process of being published. Each of these profile documents defines the use of a particular type of security token (e.g., X.509) to secure SOAP messages using digital signatures or encryption.
Username token verification specifies a process for sending Username tokens along with the message. The receiver can validate the identity of the sender by validating the digital signature sent by the sender. A digital signature internally refers to a security token (for example, Username token or an X.509 Certificate token) to indicate the key used for signing. Sending these tokens with a message binds the identity of the tokens (and any other claims occurring in the security token) to the message. For more information about these security tokens, see "Further Information".
Support for message layer security is integrated into the Application Server and its client containers in the form of (pluggable) authentication modules. By default, message layer security is disabled on the Application Server. To configure message layer security, follow the steps outlined in "Configuring the Application Server for Message Security".
The Application Server uses Username Tokens to deliver a user name and password and to authenticate the peer in the web service invocation. Username tokens are typically used in lieu of digital signatures. Digital signatures are used to bind an authentication identity to the message content. Username tokens are used to bind an authentication identity to a message sender.
When using a Username Token, a valid user database must be configured on the Application Server. For more information on this topic, read "Editing a Realm".
The Application Server uses XML Digital Signatures to authenticate the source of message content. Digital signatures is an authentication mechanism. Clients use digital signatures to establish their caller identity, analogous to the way basic authentication or SSL client certificate authentication have been used to do the same thing when transport layer security is being used. Digital signatures are used to enable the receiver to validate that the message has not be altered since it was signed, and as such can confirm that the signer defined the content (although they might not have sent it).
When using digital signatures, valid keystore and truststore files must be configured on the Application Server. For more information on this topic, read "About Certificate Files".
The purpose of encryption is to modify the data such that it can only be understood by its intended audience. This is accomplished by substituting an encrypted element for the original content. When predicated on public key cryptography, encryption can be used to establish the identity of the parties that can read a message.
When using Encryption, you must have an installed JCE provider that supports encryption. For more information on this topic, read "Configuring a JCE Provider".
The Application Server conforms to the WSS Soap Message Security specification, which can be viewed from the URL http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf. This specification is used in the Application Server’s underlying implementation of Web Services Security.
Some of the terminology used in this document is described in the WSS specification, and is summarized here. The concepts are also discussed in "Configuring the Application Server for Message Security".
The authentication layer is the message layer on which authentication processing must be performed.
In this release of the Sun Java Systems Application Server, the Application Server invokes authentication providers to process SOAP message layer security.
The default server provider is used to identify the server provider to be invoked for any application for which a specific server provider has not been bound.
The default client provider is used to identify the client provider to be invoked for any application for which a specific client provider has not been bound.
The request policy defines the authentication policy requirements associated with request processing performed by the authentication provider. Policies are expressed in message sender order such that a requirement that encryption occur after content would mean that the message receiver would expect to decrypt the message before validating the signature.
Read "Actions of Request and Response Policy Configurations" for more information on request policies.
The response policy defines the authentication policy requirements associated with response processing performed by the authentication provider. Policies are expressed in message sender order such that a requirement that encryption occur after content would mean that the message receiver would expect to decrypt the message before validating the signature.
To achieve message security, the request and response policies must be enabled on both the server and client. These policies are configured based on the type of authentication policies to be used. When configuring the policies on the client and server, make sure that the client policy matches the server policy for request/response protection at application-level message binding.
Developers can define application-specific protection policy (as opposed to overriding the default) by defining a message security binding in the Sun-specific application deployment descriptors. For more information on this topic, refer to the Securing Applications chapter of the Developers’ Guide. There is a link to this chapter in "Further Information".
Read "Actions of Request and Response Policy Configurations" for more information on response policies.
The authentication providers can perform multiple sign/encrypt operations when a corresponding flag is set on the request and/or response policies. The rules for mapping are as shown in Table 0-2.
See Also: