WAS v8.5 > Secure applications > Secure web services > Secure web services > Web Services Security concepts > Web Services Security concepts for v5.x applications

XML digital signature

XML-Signature Syntax and Processing (XML signature) is a specification that defines XML syntax and processing rules to sign and verify digital signatures for digital content. The specification was developed jointly by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF).

There is an important distinction between v5.x and v6 and later applications. The information in this article supports v5.x applications only used with WebSphere Application Server v6.0.x and later. The information does not apply to v6 and later applications.

XML signature does not introduce new cryptographic algorithms. WAS uses XML signature with existing algorithms such as RSA, HMAC, and SHA1. XML signature defines many methods for describing key information and enables the definition of a new method.

XML canonicalization (c14n) is often needed when we use XML signature. Information can be represented in various ways within serialized XML documents. For example, although their octet representations are different, the following examples are identical:

C14n is a process used to canonicalize XML information. Select an appropriate c14n algorithm because the information that is canonicalized is dependent upon this algorithm. One of the major c14n algorithms, Exclusive XML Canonicalization, canonicalizes the character encoding scheme, attribute order, namespace declarations, and so on. The algorithm does not canonicalize white space outside tags, namespace prefixes, or data type representation.


XML signature in the Web Services Security-Core specification

The Web Services Security-Core (WSS-Core) specification defines a standard way for SOAP messages to incorporate an XML signature. We can use almost all of the XML signature features in WSS-Core except enveloped signature and enveloping signature. However, WSS-Core has some recommendations such as exclusive canonicalization for the c14n algorithm and some additional features such as SecurityTokenReference and KeyIdentifier. The KeyIdentifier is the value of the SubjectKeyIdentifier field within the X.509 certificate. For more information on the KeyIdentifier, see “Reference to a Subject Key Identifier” within the OASIS Web Services Security X.509 Certificate Token Profile documentation.

By including XML signature in SOAP messages, the following are realized:

Message integrity

A message receiver can confirm that attackers or accidents have not altered parts of the message after these parts are signed by a key.

Authentication

We can assume that a valid signature is proof of possession. A message with a digital certificate issued by a certificate authority and a signature in the message that is validated successfully by a public key in the certificate, is proof the signer has the corresponding private key. The receiver can authenticate the signer by checking the trustworthiness of the certificate.


XML signature in the current implementation

XML signature is supported in Web Services Security, however, an API is not available. The current implementation has many hardcoded behaviors and has some user-operable configuration items. To configure the client for digital signature, see Configuring the client for response digital signature verification: Verifying the message parts. To configure the server for digital signature, see Configuring the server for request digital signature verification: Verifying the message parts.

Security considerations:

In a replay attack, an attacker taps the lines, receives a signed message, and then returns the message to the receiver. In this case, the receiver receives the same message twice and might process both of them if the signatures are valid. Processing both messages can cause damage to the receiver if the message is a claim for money. If we have the signed generation time stamp and the signed expiration time in a message replay, attacks might be reduced. However, this is not a complete solution. A message must have a nonce value to prevent these attacks and the receiver must reject a message containing a processed nonce. The current implementation does not provide a standard way to generate and check nonces in messages. In WAS, v5.1, nonce is supported in username tokens only. The username token profile contains concrete nonce usage scenarios for username tokens. Applications handle nonces (such as serial numbers) and they need to be signed.


Subtopics


Related concepts:

Secure web services


Related


Configure the client for response digital signature verification: verifying the message parts
Configure the client for response digital signature verification: choosing the verification method
Configure the server for request digital signature verification: Verifying the message parts
Configure the server for request digital signature verification: choosing the verification method


Related information:

Exclusive XML Canonicalization


+

Search Tips   |   Advanced Search