This chapter describes the configuration of message layer security for web services in the Application Server. This chapter contains the following topics:
Some of the material in this chapter assumes a basic understanding of security and web services concepts. To learn more about these concepts, explore the resources listed in Further Information before beginning this chapter.
In message security, security information is inserted into messages so that it travels through the networking layers and arrives with the message at the message destination(s). Message security differs from transport layer security (which is discussed in the Security chapter of the J2EE 1.4 Tutorial) in that message security can be used to decouple message protection from message transport so that messages remain protected after transmission.
Web Services Security: SOAP Message Security (WS-Security) is an international standard for interoperable Web Services Security that was developed in OASIS by a collaboration of all the major providers of web services technology (including Sun Microsystems). WS-Security is a message security mechanism that uses XML Encryption and XML Digital Signature to secure web services messages sent over SOAP. The WS-Security specification defines the use of various security tokens including X.509 certificates, SAML assertions, and username/password tokens to authenticate and encrypt SOAP web services messages.
The WS-Security specification can be viewed at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.
The Application Server offers integrated support for the WS-Security standard in its web services client and server-side containers. This functionality is integrated such that web services security is enforced by the containers of the Application Server on behalf of applications, and such that it can be applied to protect any web service application without requiring changes to the implementation of the application. The Application Server achieves this effect by providing facilities to bind SOAP layer message security providers and message protection policies to containers and to applications deployed in containers.
In the Application Server, the System Administrator and Application Deployer roles are expected to take primary responsibility for configuring message security. In some situations, the Application Developer may also contribute, although in the typical case either of the other roles may secure an existing application without changing its implementation without involving the developer. The responsibilities of the various roles are defined in the following sections:
The system administrator is responsible for:
Configuring message security providers on the Application Server.
Managing user databases.
Managing keystore and truststore files.
Configuring a Java Cryptography Extension (JCE) provider if using encryption and running a version of the Java SDK prior to version 1.5.0.
Installing the samples server. This is only done if the xms sample application will be used to demonstrate the use of message layer web services security.
A system administrator uses the Admin Console to manage server security settings and uses a command line tool to manage certificate databases. In Platform Edition, certificates and private keys are stored in key stores and are managed with keytool. Standard Edition and Enterprise Edition store certificates and private keys in an NSS database, where they are managed using certutil. This document is intended primarily for system administrators. For an overview of message security tasks, see Configuring the Application Server for Message Security.
The application deployer is responsible for:
Specifying (at application assembly) any required application-specific message protection policies if such policies have not already been specified by upstream roles (the developer or assembler).
Modifying Sun-specific deployment descriptors to specify application-specific message protection policies information (message-security-binding elements) to web service endpoint and service references.
These security tasks are discussed in the Securing Applications chapter of the Developers’ Guide. For a link to this chapter, see Further Information.
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 by the Application Deployer when the provider or protection policy bound to the application must be different from that bound to the container.
The application developer or assembler is responsible for the following:
Determining if an application-specific message protection policy is required by the application. If so, ensuring that the required policy is specified at application assembly which may be accomplished by communicating with the Application Deployer.
The WS-Security specification provides an extensible mechanism for using security tokens to authenticate and encrypt SOAP web services messages. The SOAP layer message security providers installed with the Application Server may be used to employ username/password and X.509 certificate security tokens to authenticate and encrypt SOAP web services messages. Additional providers that employ other security tokens including SAML assertions will be installed with subsequent releases of the Application Server.
The Application Server uses Username tokens in SOAP messages to establish the authentication identity of the message sender. The recipient of a message containing a Username token (within embedded password) validates that the message sender is authorized to act as the user (identified in the token) by confirming that the sender knows the secret (the password) of the user.
When using a Username token, a valid user database must be configured on the Application Server. For more information on this topic, read To edit a realm.
The Application Server uses XML Digital signatures to bind an authentication identity to message content. 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 verified by the message receiver to authenticate the source of the message content (which may be different from the sender of the message.)
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 To configure a JCE Provider.
Message protection policies are defined for request message processing and response message processing and are expressed in terms of requirements for source and/or recipient authentication. A source authentication policy represents a requirement that the identity of the entity that sent a message or that defined the content of a message be established in the message such that it can be authenticated by the message receiver. A recipient authentication policy represents a requirement that the message be sent such that the identity of the entities that can receive the message can be established by the message sender. The providers apply specific message security mechanisms to cause the message protection policies to be realized in the context of SOAP web services messages.
Request and response message protection policies are defined when a provider is configured into a container. Application-specific message protection policies (at the granularity of the web service port or operation) may also be configured within the Sun-specific deployment descriptors of the application or application client. In any case, where message protection policies are defined, the request and response message protection policies of the client must match (be equivalent to) the request and response message protection policies of the server. For more information on defining application-specific message protection policies, refer to the Securing Applications chapter of the Developers’ Guide.
The terminology used in this document is described below. The concepts are also discussed in Configuring the Application Server for Message Security.
Authentication Layer
The authentication layer is the message layer on which authentication processing must be performed. The Application Server enforces web services message security at the SOAP layer.
Authentication Provider
In this release of the Application Server, the Application Server invokes authentication providers to process SOAP message layer security.
A client-side provider establishes (by signature or username/password) the source identity of request messages and/or protects (by encryption) request messages such that they can only be viewed by their intended recipients. A client-side provider also establishes its container as an authorized recipient of a received response (by successfully decrypting it) and validates passwords or signatures in the response to authenticate the source identity associated with the response. Client-side providers configured in the Application Server can be used to protect the request messages sent and the response messages received by server-side components (servlets and EJB components) acting as clients of other services.
A server-side provider establishes its container as an authorized recipient of a received request (by successfully decrypting it) and validates passwords or signatures in the request to authenticate the source identity associated with the request. A server-side provider also establishes (by signature or username/password) the source identity of response messages and/or protects (by encryption) response messages such that they can only be viewed by their intended recipients. Server-side providers are only invoked by server-side containers.
Default Server Provider
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 server provider is sometimes referred to as the default provider.
Default Client Provider
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.
Request Policy
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.
Response Policy
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.
Web services deployed on the Application Server are secured by binding SOAP layer message security providers and message protection policies to the containers in which the applications are deployed or to web service endpoints served by the applications. SOAP layer message security functionality is configured in the client-side containers of the Application Server by binding SOAP layer message security providers and message protection policies to the client containers or to the portable service references declared by client applications.
When the Application Server is installed, SOAP layer message security providers are configured in the client and server-side containers of the Application Server, where they are available for binding for use by the containers, or by individual applications or clients deployed in the containers. During installation, the providers are configured with a simple message protection policy that, if bound to a container, or to an application or client in a container, would cause the source of the content in all request and response messages to be authenticated by XML digital signature.
The administrative interfaces of the Application Server can be employed to bind the existing providers for use by the server-side containers of the Application Server, to modify the message protection policies enforced by the providers, or to create new provider configurations with alternative message protection policies. These operations are defined in Admin Console Tasks for Security. Analogous administrative operations can be performed on the SOAP message layer security configuration of the application client container as defined in To enable message security for application clients.
By default, message layer security is disabled on the Application Server. To configure message layer security for the Application Server follow the steps outlined in Configuring the Application Server for Message Security. If you want to cause web services security to be used to protect all web services applications deployed on the Application Server, follow the steps in To enable providers for message security.
Once you have completed the above steps (which may include restarting the Application Server), web services security will be applied to all web services applications deployed on the Application Server.
Application-specific web services security functionality is configured (at application assembly) by defining message-security-binding elements in the Sun-specific deployment descriptors of the application. These message-security-binding elements are used to associate a specific provider or message protection policy with a web services endpoint or service reference, and may be qualified so that they apply to a specific port or method of the corresponding endpoint or referenced service.
For more information on defining application specific message protection policies, refer to the Securing Applications chapter of the Developers’ Guide. There is a link to this chapter in Further Information.
The Application Server ships with a sample application named xms. The xms application features a simple web service that is implemented by both a J2EE EJB endpoint and a Java Servlet endpoint. Both endpoints share the same service endpoint interface. The service endpoint interface defines a single operation, sayHello, which takes a string argument, and returns a String composed by pre-pending Hello to the invocation argument.
The xms sample application is provided to demonstrate the use of the Application Server’s WS-Security functionality to secure an existing web services application. The instructions which accompany the sample describe how to enable the WS-Security functionality of the Application Server such that it is used to secure the xms application. The sample also demonstrates the binding of WS-Security functionality directly to the application (as described in Configuring Application-Specific Web Services Security application.
The xms sample application is installed in the directory: install-dir/samples/webservices/security/ejb/apps/xms/.
For information on compiling, packaging, and running the xms sample application, refer to the Securing Applications chapter of the Developers’ Guide.
The following table shows message protection policy configurations and the resulting message security operations performed by the WS-Security SOAP message security providers for that configuration.
Table 10–1 Message protection policy to WS-Security SOAP message security operation mapping
Message Protection Policy |
Resulting WS-Security SOAP message protection operations |
---|---|
auth-source="sender" |
The message contains a wsse:Security header that contains a wsse:UsernameToken (with password). |
auth-source="content" |
The content of the SOAP message Body is signed. The message contains a wsse:Security header that contains the message Body signature represented as a ds:Signature. |
auth-source="sender" auth-recipient="before-content" OR auth-recipient="after-content" |
The content of the SOAP message Body is encrypted and replaced with the resulting xend:EncryptedData. The message contains a wsse:Security header that contains a wsse:UsernameToken (with password) and an xenc:EncryptedKey. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient. |
auth-source="content" auth-recipient="before-content" |
The content of the SOAP message Body is encrypted and replaced with the resulting xend:EncryptedData. The xenc:EncryptedData is signed. The message contains a wsse:Security header that contains an xenc:EncryptedKey and a ds:Signature. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient. |
auth-source="content" auth-recipient="after-content" |
The content of the SOAP message Body is signed, then encrypted, and then replaced with the resulting xend:EncryptedData. The message contains a wsse:Security header that contains an xenc:EncryptedKey and a ds:Signature. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient. |
auth-recipient="before-content" OR auth-recipient="after-content" |
The content of the SOAP message Body is encrypted and replaced with the resulting xend:EncryptedData. The message contains a wsse:Security header that contains an xenc:EncryptedKey. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient. |
No policy specified. |
No security operations are performed by the modules. |
The Application Server implements message security using message security providers integrated in its SOAP processing layer. The message security providers depend on other security facilities of Application Server.
If using a version of the Java SDK prior to version 1.5.0, and using encryption technology, configure a JCE provider.
Configuring a JCE provider is discussed in To configure a JCE Provider.
If using a username token, configure a user database, if necessary. When using a username/password token, an appropriate realm must be configured and an appropriate user database must be configured for the realm.
Configuring a user database is discussed in To edit a realm.
Manage certificates and private keys, if necessary.
Managing certificates and private keys is discussed in About Certificate Files.
Once the facilities of the Application Server are configured for use by message security providers, then the providers installed with the Application Server may be enabled as described in To enable providers for message security.
The Java Cryptography Extension (JCE) provider included with J2SE 1.4.x does not support RSA encryption. Because the XML Encryption defined by WS-Security is typically based on RSA encryption, in order to use WS-Security to encrypt SOAP messages you must download and install a JCE provider that supports RSA encryption.
RSA is public-key encryption technology developed by RSA Data Security, Inc. The acronym stands for Rivest, Shamir, and Adelman, the inventors of the technology.
If you are running the Application Server on version 1.5 of the Java SDK, the JCE provider is already configured properly. If you are running the Application Server on version 1.4.x of the Java SDK, you can add a JCE provider statically as part of your JDK environment, as follows.
Download and install a JCE provider JAR (Java ARchive) file.
The following URL provides a list of JCE providers that support RSA encryption: http://java.sun.com/products/jce/jce14_providers.html.
Copy the JCE provider JAR file to java-home/jre/lib/ext/.
Stop the Application Server.
If the Application Server is not stopped and then restarted later in this process, the JCE provider will not be recognized by the Application Server.
Edit the java-home/jre/lib/security/java.security properties file in any text editor. Add the JCE provider you’ve just downloaded to this file.
The java.security file contains detailed instructions for adding this provider. Basically, you need to add a line of the following format in a location with similar properties:
security.provider.n=provider-class-name |
In this example, n is the order of preference to be used by the Application Server when evaluating security providers. Set n to 2 for the JCE provider you’ve just added.
For example, if you’ve downloaded The Legion of the Bouncy Castle JCE provider, you would add this line.
security.provider.2=org.bouncycastle.jce.provider. BouncyCastleProvider |
Make sure that the Sun security provider remains at the highest preference, with a value of 1.
security.provider.1=sun.security.provider.Sun |
Adjust the levels of the other security providers downward so that there is only one security provider at each level.
The following is an example of a java.security file that provides the necessary JCE provider and keeps the existing providers in the correct locations.
security.provider.1=sun.security.provider.Sun security.provider.2=org.bouncycastle.jce.provider. BouncyCastleProvider security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.rsajca.Provider security.provider.5=com.sun.crypto.provider.SunJCE security.provider.6=sun.security.jgss.SunProvider |
Save and close the file.
Restart the Application Server.
Most of the steps for setting up the Application Server for using message security can be accomplished using the Admin Console, the asadmin command-line tool, or by manually editing system files. In general, editing system files is discouraged due to the possibility of making unintended changes that prevent the Application Server from running properly, therefore, where possible, steps for configuring the Application Server using the Admin Console are shown first, with the asadmin tool command shown after. Steps for manually editing system files are shown only when there is no Admin Console or asadmin equivalent.
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. The following sections provide the details for enabling, creating, editing, and deleting message security configurations and providers.
To enable message security for application clients
In most cases, it will be necessary to restart the Application Server after performing the administrative operations listed above. This is especially the case if you want the effects of the administrative change to be applied to applications that were already deployed on the Application Server at the time the operation was performed.
To enable message security for web services endpoints deployed in the Application Server, you must specify a provider to be used by default on the server side. If you enable a default provider for message security, you also need to enable providers to be used by clients of the web services deployed in the Application Server. Information for enabling the providers used by clients is discussed in To enable message security for application clients.
To enable message security for web service invocations originating from deployed endpoints, you must specify a default client provider. If you enabled a default client provider for the Application Server, you must ensure that any services invoked from endpoints deployed in the Application Server are compatibly configured for message layer security.
In the Admin Console tree component, expand the Configuration node.
Expand the Security node.
Expand the Message Security node.
Select the SOAP node.
Select the Message Security tab.
On the Edit Message Security Configuration page, specify a provider to be used on the server side and a provider to be used on the client side for all applications for which a specific provider has not been bound.
This is accomplished by modifying the following optional properties:
Default Provider – The identity of the server provider to be invoked for any application for which a specific server provider has not been bound.
By default, no provider configuration is selected for the Application Server. To identify a server-side provider, select ServerProvider. Selecting the null option means that no message security provider will be invoked (by default) on the server side.
You would generally select ServerProvider for this field.
Default Client Provider – The identity of the client provider to be invoked for any application for which a specific client provider has not been bound.
By default, no provider configuration is selected for the Application Server. To identify a client-side provider, select ClientProvider. Selecting the null option means that no message security provider will be invoked (by default) on the client side.
You would generally select null for this field. You would select ClientProvider if you wanted to enable a default provider and message protection policy to apply to the web services invocations originating from web services endpoints deployed on the Application Server.
Click Save.
If you enabled a client or server provider and you want to modify the message protection policies of the enabled providers, refer to To configure a message security provider for information on modifying the message security providers enabled in this step.
To specify the default server provider:
asadmin set --user admin-user --port admin-port server-config.security-service.message-security-config.SOAP. default_provider=ServerProvider |
To specify the default client provider:
asadmin set --user admin-user --port admin-port server-config.security-service.message-security-config.SOAP. default_client_provider=ClientProvider |
Typically, a provider would be reconfigured to modify its message protection policies, although the provider type, implementation class, and provider-specific configuration properties may also be modified.
In the Admin Console tree component, expand the Configuration node.
Expand the Security node.
Expand the Message Security node.
Select the SOAP node.
Select the Providers tab.
Select the message security provider to edit.
ClientProvider and ServerProvider ship with the Application Server.
In the Provider Config section of the Edit Provider Config page, the following properties are available for modification:
Provider Type – Select client, server, or client-server to establish whether the provider is to be used as a client authentication provider, a server authentication provider, or both (a client-server provider).
Class Name - Enter the Java implementation class of the provider. Client authentication providers must implement the com.sun.enterprise.security.jauth.ClientAuthModule interface. Server-side providers must implement the com.sun.enterprise.security.jauth.ServerAuthModule interface. A provider may implement both interfaces, but it must implement the interface corresponding to its provider type.
In the Request Policy section of the Create a Provider Configuration page, enter the following optional values, if needed.
These properties are optional, but if not specified, no authentication is applied to request messages.
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.
Authentication Source– Select sender, content, or null (the blank option) to define a requirement for message-layer sender authentication (for example, username password), content authentication (for example, digital signature), or no authentication be applied to request messages. When null is specified, source authentication of the request is not required.
Authentication Recipient– Select beforeContent or afterContent to define a requirement for message-layer authentication of the receiver of the request message to its sender (by XML encryption). When the value is not specified it defaults to afterContent.
For a description of the actions performed by the SOAP message security providers as a result of the following message protection policies see Actions of Request and Response Policy Configurations.
In the Response Policy section of the Create a Provider Configuration page, enter the following optional properties, if needed.
These properties are optional, but if not specified, no authentication is applied to response messages.
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.
Authentication Source – Select sender, content, or null (the blank option) to define a requirement for message-layer sender authentication (for example, username password) or content authentication (for example, digital signature) to be applied to response messages. When null is specified, source authentication of the response is not required.
Authentication Recipient – Select beforeContent or afterContent to define a requirement for message-layer authentication of the receiver of the response message to its sender (by XML encryption). When the value is not specified it defaults to afterContent.
For a description of the actions performed by the SOAP message security providers as a result of the following message protection policies see Actions of Request and Response Policy Configurations.
Add additional properties by clicking the Add Property button.
The provider that is shipped with the Application Server supports the property listed below. If other providers are used, refer to their documentation for more information on properties and valid values.
server.config – The directory and file name of an XML file that contains the server configuration information. For example, domain-dir/config/wss-server-config.xml.
Click Save.
To set the response policy, replace the word request in the following commands with response.
Add a request policy to the client and set the authentication source:
asadmin set --user admin-user --port admin-port server-config.security-service.message-security-config.SOAP. provider-config.ClientProvider.request-policy.auth_source= sender | content |
Add a request policy to the server and set the authentication source:
asadmin set --user admin-user --port admin-port server-config.security-service.message-security-config.SOAP. provider-config.ServerProvider.request-policy.auth_source= sender | content |
Add a request policy to the client and set the authentication recipient:
asadmin set --user admin-user --port admin-port server-config.security-service.message-security-config.SOAP. provider-config.ClientProvider.request-policy.auth_recipient= before-content | after-content |
Add a request policy to the server and set the authentication recipient:
asadmin set --user admin-user --port admin-port server-config.security-service.message-security-config.SOAP. provider-config.ServerProvider.request-policy.auth_recipient= before-content | after-content |
To configure an existing provider, follow the steps in To configure a message security provider.
In the Admin Console tree component, expand the Configuration node.
Expand the Security node.
Expand the Message Security node.
Select the SOAP node.
Select the Providers tab.
On the Provider Configuration page, click New.
In the Provider Config section of the Create a Provider Configuration page, enter the following:
Default Provider – Check the box beside this field to make the new message security provider the provider to be invoked for any application for which a specific provider has not been bound. Whether the provider becomes the default client provider, the default server provider, or both will be based on the value selected for Provider Type.
Provider Type – Select client, server, or client-server to establish whether the provider is to be used as a client authentication provider, a server authentication provider, or both (a client-server provider).
Provider ID - Enter an identifier for this provider configuration. This name will appear in the Current Provider Configurations list.
Class Name - Enter the Java implementation class of the provider. Client authentication providers must implement the com.sun.enterprise.security.jauth.ClientAuthModule interface. Server-side providers must implement the com.sun.enterprise.security.jauth.ServerAuthModule interface. A provider may implement both interfaces, but it must implement the interface corresponding to its provider type.
In the Request Policy section of the Create a Provider Configuration page, enter the following optional values, if needed.
These properties are optional, but if not specified, no authentication is applied to request messages.
Authentication Source – Select sender, content, or null (the blank option) to define a requirement for message-layer sender authentication (for example, username password), content authentication (for example, digital signature), or no authentication be applied to request messages. When null is specified, source authentication of the request is not required.
Authentication Recipient – Select beforeContent or afterContent to define a requirement for message-layer authentication of the receiver of the request message to its sender (by XML encryption). When the value is not specified it defaults to afterContent.
For a description of the actions performed by the SOAP message security providers as a result of the following message protection policies see Actions of Request and Response Policy Configurations.
In the Response Policy section of the Create a Provider Configuration page, enter the following optional properties, if needed.
These properties are optional, but if not specified, no authentication is applied to response messages.
Authentication Source – Select sender, content, or null (the blank option) to define a requirement for message-layer sender authentication (for example, username password) or content authentication (for example, digital signature) to be applied to response messages. When null is specified, source authentication of the response is not required.
Authentication Recipient – Select beforeContent or afterContent to define a requirement for message-layer authentication of the receiver of the response message to its sender (by XML encryption). When the value is not specified it defaults to afterContent.
For a description of the actions performed by the SOAP message security providers as a result of the following message protection policies see Actions of Request and Response Policy Configurations.
Add additional properties by clicking the Add Property button.
The provider that is shipped with the Application Server supports the property listed below. If other providers are used, refer to their documentation for more information on properties and valid values.
server.config – The directory and file name of an XML file that contains the server configuration information. For example, domain-dir/config/wss-server-config.xml.
Click OK to save this configuration, or click Cancel to quit without saving.
create-message-security-provider
In the Admin Console tree component, expand the Configuration node.
Expand the Security node.
Select the Message Security node.
Click in the checkbox to the left of the Message Security Configuration to be deleted.
Click Delete.
In the Admin Console tree component, expand the Configuration node.
Expand the Security node.
Expand the Message Security node.
Select the SOAP node.
Select the Providers page.
Click in the checkbox to the left of the Provider Configuration to be deleted.
Click Delete.
delete-message-security-provider
The message protection policies of client providers must be configured such that they are equivalent to the message protection policies of the server-side providers they will be interacting with. This is already the case for the providers configured (but not enabled) when the Application Server is installed.
To enable message security for client applications, modify the Application Server specific configuration for the application client container.
Stop any client applications that depend on the client container descriptor.
In a text editor, open the Sun application client container descriptor, located in domain-dir/config/sun-acc.xml.
Add the default-client-provider element to the file to enable the default client provider in the application client.
The other code is provided to show where the code to enable message security for client applications should be located. The other code may differ slightly in your installation. Do not change it.
<client-container> <target-server name="your-host" address="your-host" port="your-port"/> <log-service file="" level="WARNING"/> <message-security-config auth-layer="SOAP" default-client-provider="ClientProvider"> <provider-config class-name="com.sun.enterprise.security.jauth.ClientAuthModule" provider-id="ClientProvider" provider-type="client"> <request-policy auth-source="sender"/> <response-policy/> <property name="security.config" value="C:/Sun/AppServer/lib/appclient/wss-client-config.xml"/> </provider-config> </message-security-config> </client-container> |
The message security provider configured in the client container will also require access to private keys and trusted certificates. This is accomplished by defining appropriate values for the following system properties in the application client startup script.
-Djavax.net.ssl.keyStore
-Djavax.net.ssl.trustStore
The request and response policies define the authentication policy requirements associated with request and 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. 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.
To set the request policy for the application client configuration, modify the Application Server specific configuration for the application client container as described in To enable message security for application clients. In the application client configuration file, add the request-policy and response-policy elements as shown to set the request policy.
The other code is provided for reference. The other code may differ slightly in your installation. Do not change it.
<client-container> <target-server name="your-host" address="your-host" port="your-port"/> <log-service file="" level="WARNING"/> <message-security-config auth-layer="SOAP" default-client-provider="ClientProvider"> <provider-config class-name="com.sun.enterprise.security.jauth.ClientAuthModule" provider-id="ClientProvider" provider-type="client"> <request-policy auth-source="sender | content" auth-recipient="after-content | before-content"/> <response-policy auth-source="sender | content" auth-recipient="after-content | before-content"/> <property name="security.config" value="install-dir/lib/appclient/wss-client-config.xml"/> </provider-config> </message-security-config> </client-container> |
Valid values for auth-source include sender and content. Valid values for auth-recipient include before-content and after-content. A table describing the results of various combinations of these values can be found in Actions of Request and Response Policy Configurations.
To not specify a request or response policy, leave the element blank, for example:
<response-policy/> |
The Java 2 Standard Edition discussion of security can be viewed from http://java.sun.com/j2se/1.4.2/docs/guide/security/index.html.
The J2EE 1.4 Tutorial chapter titled Security can be viewed from http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html.
The Administration Guide chapter titled Chapter 9, Configuring Security.
The Developer’s Guide chapter titled Securing Applications.
The Oasis Web Services Security: SOAP Message Security (WS-Security) specification, can be viewed from http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.
The OASIS Web Services Security Username Token Profile 1.0, can be found at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf.
The OASIS Web Services Security X.509 Certificate Token Profile 1.0, can be found at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf.
The XML-Signature Syntax and Processing document can be viewed at http://www.w3.org/TR/xmldsig-core/.
The XML Encryption Syntax and Processing document can be viewed at http://www.w3.org/TR/xmlenc-core/.