Secure Web services applications using the WSS APIs at the message level

Standards and profiles address how to provide protection for messages that are exchanged in a Web service environment. WS-Security is a message-level standard that is based on securing SOAP messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens.

To secure Web services, consider a broad set of security requirements, including authentication, authorization, privacy, trust, integrity, confidentiality, secure communications channels, 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 interoperate between formerly incompatible security technologies in heterogeneous environments. The complete WS-Security protocol stack and technology roadmap is described in the Web services roadmap.

The Organization for the Advancement of Structured Information Standards (OASIS) WS-Security: SOAP Message Security V1.1 specification is the basic messaging transport for all Web services. SOAP 1.2 adds extensions to the existing SOAP 1.1 extensions so that we can build secure Web services. Attachments can be added to SOAP messages by using Message Transmission Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP) instead of the SOAP with Attachments (SWA) profile.

The OASIS WS-Security V1.1 spec is the building block used in conjunction with other Web service and application-specific protocols to accommodate a wide variety of security models. WS-Security for WAS is based on specific standards that are included in the OASIS WS-Security V1.1 spec and profiles.

The V1.1 specification defines additional facilities for protecting the integrity and confidentiality of a message. The V1.1 spec also provides the mechanisms for associating security-related claims with the message. The WS-Security Version 1.1 standards that are supported by WAS include the signature confirmation, encrypted header elements, the Username Token Profile and the X.509 Token Profile. The Username Token Profile and the X.509 Token Profile have been updated as V1.1 profiles. For the X.509 Certificate Token Profile, one new type of security token reference is the Thumbprint reference, which is specified in the binding.

XML Schema, Part 1 and Part 2 are specifications that explain how schemas are organized in XML documents. The two WS-Security V1.0 schemas have been updated to the V1.1 specifications plus a new V1.1 schema has been added. Note that the Version 1.1 schema does not replace the V1.0 schema but instead builds upon it by defining an additional set of capabilities within a V1.1 namespace. Use the following methods to configure Web services security and to define policy types to secure the SOAP messages:

• Use the admin console to configure policy sets.

  This method uses the bootstrap policy that is defined in the policy set. We can use policy sets, or assertions about how services are defined, to simplify your security configuration for Web services. Use the admin console to create, modify, and delete custom policy sets. A set of default policy sets are available.

  For example, we can define the bootstrap policy in the policy set to secure the Web Services Trust (WS-Trust) SOAP messages.

  We can also use the admin console to perform policy set management tasks and to secure Web Services using encryption, signing information, and security tokens.

  The following steps high-level steps describe how to configure WAS to use WS-Security and to secure the SOAP messages using the admin console. The generator and consumer tasks that are discussed in the following steps use WS-Security Versions 1.0 and 1.1.

  • Create and configure the application policy sets or the system policy sets for trust service.

  • Define the policy types to be used to secure the SOAP messages when creating and configuring the policy sets.

  • Set the policy set binding. Select either the symmetric or asymmetric binding assertion to describe the token type and the algorithm to be used for message protection.

  • Assemble the WS-Security-enabled application by using an assembly tool.

• Use the WS-Security APIs (WSS API) to configure the SOAP message context (only for the client)

  WAS uses a new API model. In addition to the existing JAX-RPC programming model, a new model, Java API for XML Web Services (JAX-WS), has been added. The JAX-WS programming standard aligns with the document-centric messaging model and replaces the remote procedure call model defined by the JAX-RPC specification.

  For example, an application could create system policy sets and then use the WAS WSS API to acquire the security context token for programmatic API-based Web Services Secure Conversation (WS-SecureConversation).

  We can also use the admin console to perform the encryption, signing, and token configuration tasks that the WSS APIs perform to secure Web services.

  The following high-level steps describe how to configure WAS to use WS-Security and to secure the SOAP messages using the WSS APIs. The generator and consumer tasks that are discussed in the following steps use WS-Security Versions 1.0 and 1.1.

  • Use the WSSSignature API to configure the signing information for the request generator (client side) binding.

    Different message parts can be specified in the message protection for a request on the generator side. The default required parts are BODY, ADDRESSING_HEADERS and TIMESTAMP.

    The WSSSignature API also specifies the different algorithm methods to be used with the signature for message protection. The default signature method is RSA_SHA1. The default canonicalization method is EXC_C14N.

  • Use the WSSSignPart API to change the digest method and the transform method.

    The default signed parts are WSSSignature.BODY, WSSSignature.ADDRESSING_HEADERS and WSSSignature.TIMESTAMP.

    The WSSSignPart API also specifies the different algorithm methods to be used if we added or changed the signed parts. The default digest method is SHA1. The default transform method is TRANSFORM_EXC_C14N.

    For example, use the WSSSignPart API to generate the signature for the SOAP message using the SHA256 digest method instead of the default value of SHA1.

  • Use the WSSEncryption API to configure the encryption information on the request generator side.

    The encryption information on the generator side is used for encrypting an outgoing SOAP message for the request generator (client side) bindings. The default targets of encryption are BODY_CONTENT and SIGNATURE.

    The WSSEncryption API also specifies the different algorithm methods to be used to protect message confidentiality. The default data encryption method is AES128. The default key encryption method is KW_RSA_OAEP.

  • Use the WSSEncryptPart API to set the transform method only.

    For example, to change the data encryption method from the default value of AES128 to TRIPLE_DES.

    No algorithm methods are required for encrypted parts.

  • Use the WSS API to configure the token on the generator side.

    The requirements for the security token depend on the token type. The JAAS Login Module and the JAAS CallbackHandler are responsible for creating the security token on the generator side. Different standalone tokens can be sent in request and response. The default token is the X509Token. The other token that can be used for signing is the DerivedKeyToken, which is used only with Web Services Secure Conversation (WS-SecureConversation).

  • Use the WSSVerification API to verify the signature for the response consumer (client side) binding.

    Different message parts can be specified in the message protection for a response on the consumer side. The required targets for verification are BODY, ADDRESSING_HEADERS and TIMESTAMP.

    The WSSVerification API also specifies the different algorithm methods to be used for verifying the signature and for message protection. The default signature method is RSA_SHA1. The default canonicalization method is EXC_C14N.

  • Use the WSSVerifyPart API to change the digest method and the transform method. The required verify parts are WSSVerification.BODY, WSSVerification.ADDRESSING_HEADERS and WSSVerification.TIMESTAMP.

    The WSSVerifyPart API also specifies the different algorithm methods to be used if we added or changed the verification parts. The default digest method is SHA1. The default transform method is TRANSFORM_EXC_C14N.

  • Use the WSSDecryption API to configure the decryption information for the response consumer (client side) binding.

    The decryption information on the consumer side is used for decrypting an incoming SOAP message. The targets of decryption are BODY_CONTENT and SIGNATURE. The default key encryption method is KW_RSA_OAEP.

    No algorithm methods are required for decryption.

  • Use the WSSDecryptPart API to set the transform method only.

    For example, to change the data encryption method from the default value of AES128 to TRIPLE_DES.

    No algorithm methods are required for decrypted parts.

  • Use the WSS API to configure the token on the consumer side.

    The requirements for the security token depend on the token type. The JAAS Login Module and the JAAS CallbackHandler are responsible for validating (authenticating) the security token on the consumer side. Different standalone tokens can be sent in request or response.

    The WSS API adds the information for the candidate token used for decryption. The default token is X509Token.

• Use the wsadmin admin scripting tool to configure policy sets.

  This method allows you to create, manage, and delete policy sets from the command-line or to create scripts to automate the tasks. Use wsadmin and the PolicySetManagement command group to manage default policy sets, create custom policy sets, configure policies, and manage attachments and bindings.

  See, use the policy set scripting topics in the information center.

To secure Web services with WAS, configure the generator and the consumer security constraints. You must specify several different configurations. Although there is no specific sequence to specify these different configurations, some configurations reference other configurations. For example, decryption configurations reference encryption configurations.

 

Results

After completing these high-level steps for WAS, you have secured Web services by configuring policy sets and by using the WSS API to configure encryption and decryption, the signature and signature verification information, and the consumer and generator tokens.

Secure messages at the request generator using WSS APIs
Secure messages at the response consumer using WSS APIs
Set WS-Security using the WSS APIs
Encrypted SOAP headers
Signature confirmation

 

Related concepts

WS-Security API model

 

Related tasks

Set application and system policy sets for Web services using scripting
Secure JAX-WS Web services using message-level security

 

Related

WS-Security APIs
PolicySetManagement
Web services specifications and APIs

 

Related information

WS-Security: SOAP Message Security V 1.1 specification
Security in a Web Services World: A Proposed Architecture and Roadmap