Secure Web services for V5.x applications based on WS-Security
WS-Security for WAS is based on standards included in the WS-Security specification. These standards address how to provide protection for messages exchanged in a Web service environment.
There is an important distinction between Version 5.x and V6 and later applications. The information in this article supports V5.x applications only that are used with WAS V6.0.x and later. The information does not apply to V6 and later applications.
The specification defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the message. WS-Security is a message-level standard based on securing SOAP messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens.
Restriction: WAS V5.x implements the JAX-RPC 1.1 standard. You can use policy sets only with JAX-WS applications. We cannot use policy sets with JAX-RPC applications.
To secure Web services, consider a broad set of security requirements, including authentication, authorization, privacy, trust, integrity, confidentiality, secure communications channels, federation, delegation, and auditing across a spectrum of application and business topologies. One of the key requirements for the security model in today's business environment is the ability to inter-operate between formerly incompatible security technologies, such as public key infrastructure and Kerberos in heterogeneous environments like Microsoft .NET and environments that are based on the Java EE standards. The complete Web services security protocol stack and technology roadmap is described in Security in a Web Services World: A Proposed Architecture and Roadmap.
Specification: WS-Security proposes a standard set of SOAP extensions that we can use to build secure Web services. These standards confirm integrity and confidentiality, which are generally provided with digital signature and encryption technologies. In addition, WS-Security provides a general purpose mechanism for associating security tokens with messages. A typical example of the security token is a user name and password token, in which a user name and password are included as text. Web services security defines how to encode binary security tokens using methods such as X.509 certificates and Kerberos tickets.
To establish a secured environment and to enforce constraints for Web services security, perform a JNDI lookup on the client to resolve the service reference.
An administrator can use any of the following methods to integrate message-level security into a WAS environment:
- Secure Web services for V5.x applications using XML digital signature
- Secure Web services for V5.x applications using XML encryption
- Secure Web services for V5.x applications using basic authentication
- Secure Web services for V5.x applications using identity assertion authentication
- Secure Web services for version 5.x applications using signature authentication
- Secure Web services for version 5.x applications using a pluggable token
Example
WAS provides the following sample keystores for sample configurations. These sample keystores are for testing and sample purposes only. Do not use them a in production environment.
- ${USER_INSTALL_ROOT}/etc/ws-security/samples/dsig-sender.ks
- The keystore password is client
- Trusted certificate with alias name, soapca
- Personal certificate with alias name, soaprequester and key password client issued by intermediary certificate authority Int CA2, which is, in turn, issued by soapca
- ${USER_INSTALL_ROOT}/etc/ws-security/samples/dsig-receiver.ks
- The keystore password is server
- Trusted certificate with alias name, soapca
- Personal certificate with alias name, soapprovider and key password server, issued by intermediary certificate authority Int CA2, which is, in turn, issued by soapca
- ${USER_INSTALL_ROOT}/etc/ws-security/samples/enc-sender.jceks
- The keystore password is storepass
- Secret key CN=Group1, alias name Group1, and key password keypass
- Public key CN=Bob, O=IBM, C=US, alias name bob, and key password keypass
- Private key CN=Alice, O=IBM, C=US, alias name alice, and key password keypass
- ${USER_INSTALL_ROOT}/etc/ws-security/samples/enc-receiver.jceks
- The keystore password is storepass
- Secret key CN=Group1, alias name Group1, and key password keypass
- Private key CN=Bob, O=IBM, C=US, alias name bob, and key password keypass
- Public key CN=Alice, O=IBM, C=US, alias name alice, and key password keypass
- ${USER_INSTALL_ROOT}/etc/ws-security/samples/intca2.cer
- The intermediary certificate authority is Int CA2.
Default binding (cell and server level) WAS provides the following default binding information:
- Trust anchors
- Used to validate the trust of the signer certificate.
- SampleClientTrustAnchor is used by the response receiver to validate the signer certificate.
- SampleServerTrustAnchor is used by the request receiver to validate the signer certificate.
- Collection Certificate Store
- Used to validate the certificate path.
- SampleCollectionCertStore is used by the response receiver and the request receiver to validate the signer certificate path.
- Key Locators
- Used to locate the key for signature, encryption, and decryption.
- SampleClientSignerKey is used by the requesting sender to sign the SOAP message. The signing key name is clientsignerkey, which can be referenced in the signing information as the signing key name.
- SampleServerSignerKey is used by the responding sender to sign the SOAP message. The signing key name is serversignerkey, which can be referenced in the signing information as the signing key name.
- SampleSenderEncryptionKeyLocator is used by the sender to encrypt the SOAP message. It is configured to use the ${USER_INSTALL_ROOT}/etc/ws-security/samples/enc-sender.jceks keystore and the com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator keystore key locator.
- SampleReceiverEncryptionKeyLocator is used by the receiver to decrypt the encrypted SOAP message. The implementation is configured to use the ${USER_INSTALL_ROOT}/etc/ws-security/samples/enc-receiver.jceks keystore and the com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator keystore key locator. The implementation is configured for symmetric encryption (DES or TRIPLEDES). However, to use it for asymmetric encryption (RSA), add the private key CN=Bob, O=IBM, C=US, alias name bob, and key password keypass.
- SampleResponseSenderEncryptionKeyLocator is used by the response sender to encrypt the SOAP response message. It is configured to use the ${USER_INSTALL_ROOT}/etc/ws-security/samples/enc-receiver.jceks keystore and the com.ibm.wsspi.wssecurity.config.WSIdKeyStoreMapKeyLocator key locator. This key locator maps an authenticated identity (of the current thread) to a public key for encryption. By default, WAS is configured to map to public key alice, and change WAS to the appropriate user. The SampleResponseSenderEncryptionKeyLocator key locator also can set a default key for encryption. By default, this key locator is configured to use public key alice.
- Trusted ID Evaluator
- Used to establish trust before asserting to the identity in identity assertion.SampleTrustedIDEvaluator is configured to use the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl implementation. The default implementation of com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator contains a list of trusted identities. The list is defined as properties with trustedId_* as the key and the value as the trusted identity. Define this information for the server level in the administration console by completing the following steps:
For the cell level, click Security > Web Services > Trusted ID Evaluators > SampleTrustedIDEvaluator.
- Click Servers > Application Servers > server1.
- Under Additional Properties, click Web Services: Default bindings for WS-Security > Trusted ID Evaluators > SampleTrustedIDEvaluator.
- Login Mapping
- Used to authenticate the incoming security token in the Web services security SOAP header of a SOAP message.
- The BasicAuth authentication method is used to authenticate user name security token (user name and password).
- The Signature authentication method is used to map a distinguished name (DN) into a WAS Java Authentication and Authorization Server (JAAS) Subject.
- The IDAssertion authentication method is used to map a trusted identity into a WAS JAAS Subject for identity assertion.
- The LTPA authentication method is used to validate a LTPA security token.
The previous default bindings for trust anchors, collection certificate stores, and key locators are for testing or sample purpose only. Do not use them for production.
A sample configuration
The following examples demonstrate what IBM deployment descriptor extensions and bindings can do. The unnecessary information was removed from the examples to improve clarity. Do not copy and paste these examples into the application deployment descriptors or bindings. These examples serve as reference only and are not representative of the recommended configuration. Use the following tools to create or edit IBM deployment descriptor extensions and bindings:
- Use an assembly tool to create or edit the IBM deployment descriptor extensions.
- Use an assembly tool or the admin console to create or edit the bindings file.
The following example illustrates a scenario that:
- Signs the SOAP body, time stamp, and security token.
- Encrypts the body content and user name token.
- Sends the user name token (basic authentication data).
- Generates the time stamp for the request.
For the response, the SOAP body and time stamp are signed, the body content is encrypted, and the SOAP message freshness is checked using the time stamp. The freshness of the message indicates whether the message complies with predefined time constraints. The request sender and the request receiver are a pair. Similarly, the response sender and the response receiver are a pair.
Tip: It is recommended that you use the WAS variables for specifying the path to the key stores. In the admin console, click Environment > Manage WebSphere Variables. These variables often help with platform differences such as file system naming conventions. In the following examples, $${USER_INSTALL_ROOT} is used for specifying the path to the key stores.
Client-side IBM deployment descriptor extension
The client-side IBM deployment descriptor extension describes the following constraints: Request Sender
- Signs the SOAP body, time stamp and security token
- Encrypts the body content and user name token
- Sends the basic authentication token (user name and password)
- Generates the time stamp to expire in three minutes
Response Receiver
- Verifies that the SOAP body and time stamp are signed
- Verifies that the SOAP body content is encrypted
- Verifies that the time stamp is present (also check for message freshness)
Example 1: Sample client IBM deployment descriptor extension The xmi:id statements are removed for readability. These statements must be added for this example to work.
In the following code sample, lines 2 through 4 were split into three lines due to the width of the printed page.
<?xml version="1.0" encoding="UTF-8"?> <com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext= http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi"> <serviceRefs serviceRefLink="service/myServ"> <portQnameBindings portQnameLocalNameLink="Port1"> <clientServiceConfig actorURI="myActorURI"> <securityRequestSenderServiceConfig actor="myActorURI"> <integrity> <references part="body"/> <references part="timestamp"/> <references part="securitytoken"/> </integrity> <confidentiality> <confidentialParts part="bodycontent"/> <confidentialParts part="usernametoken"/> </confidentiality> <loginConfig authMethod="BasicAuth"/> <addCreatedTimeStamp flag="true" expires="PT3M"/> </securityRequestSenderServiceConfig> <securityResponseReceiverServiceConfig> <requiredIntegrity> <references part="body"/> <references part="timestamp"/> </requiredIntegrity> <requiredConfidentiality> <confidentialParts part="bodycontent"/> </requiredConfidentiality> <addReceivedTimeStamp flag="true"/> </securityResponseReceiverServiceConfig> </clientServiceConfig> </portQnameBindings> </serviceRefs> </com.ibm.etools.webservice.wscext:WsClientExtension>Client-side IBM extension bindings
Example 2 shows the client-side IBM extension binding for the security constraints described previously in the discussion on client-side IBM deployment descriptor extensions.
The signer key and encryption (decryption) key for the message can be obtained from the keystore key locator implementation (com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator). The signer key is used for encrypting the response. The sample is configured to use the Java Certification Path API to validate the certificate path of the signer of the digital signature. The user name token (basic authentication) data is collected from the standard in (stdin) prompts using one of the default JAAS implementations :javax.security.auth.callback.CallbackHandler implementation (com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler).
Example 2: Sample client IBM extension binding
In the following code sample, several lines were split into multiple lines due to the width of the printed page. See the close bracket for an indication of where each line of code ends.
<?xml version="1.0" encoding="UTF-8"?> <com.ibm.etools.webservice.wscbnd:ClientBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscbnd= "http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscbnd.xmi"> <serviceRefs serviceRefLink="service/MyServ"> <portQnameBindings portQnameLocalNameLink="Port1"> <securityRequestSenderBindingConfig> <signingInfo> <signatureMethod algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <signingKey name="clientsignerkey" locatorRef="SampleClientSignerKey"/> <canonicalizationMethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <digestMethod algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> </signingInfo> <keyLocators name="SampleClientSignerKey" classname= "com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator"> <keyStore storepass="{xor}PDM2OjEr" path= "$${USER_INSTALL_ROOT}/etc/ws-security/samples/dsig-sender.ks" type="JKS"/> <keys alias="soaprequester" keypass="{xor}PDM2OjEr" name="clientsignerkey"/> </keyLocators> <encryptionInfo name="EncInfo1"> <encryptionKey name="CN=Bob, O=IBM, C=US" locatorRef= "SampleSenderEncryptionKeyLocator"/> <encryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <keyEncryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> </encryptionInfo> <keyLocators name="SampleSenderEncryptionKeyLocator" classname= "com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator"> <keyStore storepass="{xor}LCswLTovPiws" path= "$${USER_INSTALL_ROOT}/etc/ws-security/samples/enc-sender.jceks" type="JCEKS"/> <keys alias="Group1" keypass="{xor}NDomLz4sLA==" name="CN=Group1"/> </keyLocators> <loginBinding authMethod="BasicAuth" callbackHandler= "com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler"/> </securityRequestSenderBindingConfig> <securityResponseReceiverBindingConfig> <signingInfos> <signatureMethod algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <certPathSettings> <trustAnchorRef ref="SampleClientTrustAnchor"/> <certStoreRef ref="SampleCollectionCertStore"/> </certPathSettings> <canonicalizationMethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <digestMethod algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> </signingInfos> <trustAnchors name="SampleClientTrustAnchor"> <keyStore storepass="{xor}PDM2OjEr" path= "$${USER_INSTALL_ROOT}/etc/ws-security/samples/dsig-sender.ks" type="JKS"/> </trustAnchors> <certStoreList> <collectionCertStores provider="IBMCertPath" name="SampleCollectionCertStore"> <x509Certificates path="$${USER_INSTALL_ROOT}/etc/ws-security/samples/intca2.cer"/> </collectionCertStores> </certStoreList> <encryptionInfos name="EncInfo2"> <encryptionKey locatorRef="SampleReceiverEncryptionKeyLocator"/> <encryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <keyEncryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> </encryptionInfos> <keyLocators name="SampleReceiverEncryptionKeyLocator" classname= "com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator"> <keyStore storepass="{xor}PDM2OjEr" path= "$${USER_INSTALL_ROOT}/etc/ws-security/samples/dsig-sender.ks" type="JKS"/> <keys alias="soaprequester" keypass="{xor}PDM2OjEr" name="clientsignerkey"/> </keyLocators> </securityResponseReceiverBindingConfig> </portQnameBindings> </serviceRefs> </com.ibm.etools.webservice.wscbnd:ClientBinding>Server-side IBM deployment descriptor extension
The client-side IBM deployment descriptor extension describes the following constraints: Request Receiver (ibm-webservices-ext.xmi and ibm-webservices-bnd.xmi)
- Verifies that the SOAP body, time stamp, and security token are signed.
- Verifies that the SOAP body content and user name token are encrypted.
- Verifies that the basic authentication token (user name and password) is in the WS-Security SOAP header.
- Verifies that the time stamp is present (also check for message freshness). The freshness of the message indicates whether the message complies with predefined time constraints.
Response Sender (ibm-webservices-ext.xmi and ibm-webservices-bnd.xmi)
- Signs the SOAP body and time stamp
- Encrypts the SOAP body content
- Generates the time stamp to expire in 3 minutes
Example 3: Sample server IBM deployment descriptor extension
In the following code sample, several lines were split into multiple lines due to the width of the printed page. See the close bracket for an indication of where each line of code ends.
<?xml version="1.0" encoding="UTF-8"?> <com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext= http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi"> <wsDescExt wsDescNameLink="MyServ"> <pcBinding pcNameLink="Port1"> <serverServiceConfig actorURI="myActorURI"> <securityRequestReceiverServiceConfig> <requiredIntegrity> <references part="body"/> <references part="timestamp"/> <references part="securitytoken"/> </requiredIntegrity> <requiredConfidentiality"> <confidentialParts part="bodycontent"/> <confidentialParts part="usernametoken"/> </requiredConfidentiality> <loginConfig> <authMethods text="BasicAuth"/> </loginConfig> <addReceivedTimestamp flag="true"/> </securityRequestReceiverServiceConfig> <securityResponseSenderServiceConfig actor="myActorURI"> <integrity> <references part="body"/> <references part="timestamp"/> </integrity> <confidentiality> <confidentialParts part="bodycontent"/> </confidentiality> <addCreatedTimestamp flag="true" expires="PT3M"/> </securityResponseSenderServiceConfig> </serverServiceConfig> </pcBinding> </wsDescExt> </com.ibm.etools.webservice.wsext:WsExtension>Server-side IBM extension bindings
The following binding information reuses some of the default binding information defined either at the server level or the cell level, which depends upon the installation. For example, request receiver is referencing the SampleCollectionCertStore certification store and the SampleServerTrustAnchor trust store is defined in the default binding. However, the encryption information in the request receiver is referencing a SampleReceiverEncryptionKeyLocator key locator defined in the application-level binding (the same ibm-webservices-bnd.xmi file). The response sender is configured to use the signer key of the digital signature of the request to encrypt the response using one of the default key locator (com.ibm.wsspi.wssecurity.config.CertInRequestKeyLocator) implementations.
Example 4: Sample server IBM extension binding
<?xml version="1.0" encoding="UTF-8"?> <com.ibm.etools.webservice.wsbnd:WSBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsbnd= http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsbnd.xmi"> <wsdescBindings wsDescNameLink="MyServ"> <pcBindings pcNameLink="Port1" scope="Session"> <securityRequestReceiverBindingConfig> <signingInfos> <signatureMethod algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <certPathSettings> <trustAnchorRef ref="SampleServerTrustAnchor"/> <certStoreRef ref="SampleCollectionCertStore"/> </certPathSettings> <canonicalizationMethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <digestMethod algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> </signingInfos> <encryptionInfos name="EncInfo1"> <encryptionKey locatorRef="SampleReceiverEncryptionKeyLocator"/> <encryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <keyEncryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> </encryptionInfos> <keyLocators name="SampleReceiverEncryptionKeyLocator" classname= "com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator"> <keyStore storepass="{xor}LCswLTovPiws" path="$${USER_INSTALL_ROOT}/ etc/ws-security/samples/enc-receiver.jceks" type="JCEKS"/> <keys alias="Group1" keypass="{xor}NDomLz4sLA==" name="CN=Group1"/> <keys alias="bob" keypass="{xor}NDomLz4sLA==" name="CN=Bob, O=IBM, C=US"/> </keyLocators> </securityRequestReceiverBindingConfig> <securityResponseSenderBindingConfig> <signingInfo> <signatureMethod algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <signingKey name="serversignerkey" locatorRef="SampleServerSignerKey"/> <canonicalizationMethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <digestMethod algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> </signingInfo> <encryptionInfo name="EncInfo2"> <encryptionKey locatorRef="SignerKeyLocator"/> <encryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <keyEncryptionMethod algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> </encryptionInfo> <keyLocators name="SignerKeyLocator" classname= "com.ibm.wsspi.wssecurity.config.CertInRequestKeyLocator"/> </securityResponseSenderBindingConfig> </pcBindings> </wsdescBindings> <routerModules transport="http" name="StockQuote.war"/> </com.ibm.etools.webservice.wsbnd:WSBinding>
WS-Security specification—a chronology
WS-Security support
WS-Security and Java EE security relationship
WS-Security model in WAS
Propagating security tokens
WS-Security constraints
Overview of authentication methods
Overview of token types
XML digital signature
Secure Web services for V5.x applications using XML digital signature
XML encryption
Secure Web services for V5.x applications using XML encryption
Secure Web services for V5.x applications using basic authentication
Identity assertion in a SOAP message
Secure Web services for V5.x applications using identity assertion authentication
Secure Web services for version 5.x applications using signature authentication
Security token
Secure Web services for version 5.x applications using a pluggable token
Tuning WS-Security for V5.x applications
Related tasks
Secure Web services applications using message level security
Related
Default bindings and runtime properties for WS-Security
Web services specifications and APIs 
Related information
Security in a Web Services World: A Proposed Architecture and Roadmap
Specification: WS-Security