File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services Certification (SCDJWS/OCEJWSD) and the fly likes Question on XML Signature Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Services Certification (SCDJWS/OCEJWSD)
Bookmark "Question on XML Signature" Watch "Question on XML Signature" New topic
Author

Question on XML Signature

Kumar Raja
Ranch Hand

Joined: Mar 18, 2010
Posts: 516
    
    2

Hi All,

I'm not sure, if I need to post this in XML forum, but thought of referring it here as this is a part of WS-Security suite. I'm articulating some questions based on my reading on XML Encryption and XML Signature and would appreciate, if you could guide me, if my understanding is correct and correct me.

1) XML Encryption - This is used for confidentiality purpose only - So that no body would tamper the message in the transit.

2) XML Signature - This is used for Message integrity, authenticity and Non-repudiation.

WS-Security implements the above two features using X509 certificates.

3) In the document XML Digital Signature, it is mentioned that a canonicalized form of "SignedInfo" element is calculated and digest is calculated on this canonicalized result. The intention of the signing is to sign the document that is being referred through "Reference" element and not the "SignedInfo". Then why do we need to canonicalize, digest and sign the "SignedInfo" element instead of the document being referred.

Similarly for verifying the signature, we are acting first on SignedInfo, by calculating the digest and then verifying the digest of the referred. Why this two steps are needed here. Why do we actually need to create the digest of the SignedInfo, as we do digest the actual document.

4) Is my understanding about Enveloped and Enveloping correct ?
a) Enveloped Signature - Signature element forms a child element of the document that is signed.
b) Enveloping Signature - Signature element contains the document that is signed as child.

5) I saw examples where some kind of api being used for generating XML Encryption and XML Signature. But using these features in WS, (where in they form the part of header blocks), are there any annotations available? If yes, can some one point me to links which demonstrates this with an example for both Java first and contract first approaches.

6) In typical situations, SAML is used for Identity management for controlling single sign on, but can use XACML to take access decision making.

7) Is there any recommended order of applying XML signature and XML encryption. I'm thinking Encryption first and Signing next. Please share your thoughts.

8) One more question which I wanted to add here is about UserNameToken. I was reading through the article written on UserNameToken implementation of Rampart and my understanding after reading this was a password digest is calculated by calculating digest on the concat of the actual password + Nonce + created timestamp and the value is Base64Encoded. Now this resultant goes into UserNameToken along with Usrename, Nonce and timestamp.

At the receiving end, the digest is recalculated and then compared with what received. But on what the digest is recalculated. I knew that receiver gets the Nonce and Timestamp, but when does it get the password. So, my assumption was based on the username, it would search for the password in its database (or by some other means), concat that password with received Nonce and Timestamp, calculate the digest and base64encode. The resultant string is compared with the digest that is received.

Is this how it would work?


Regards
KumarRaja

Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Kumar,

It's a lot. About -
1) XML Encryption - This is used for confidentiality purpose only - So that nobody would tamper the message in the transit.
.

Ok, so about - So that nobody would tamper the message in the transit - that's actually data integrity as data integrity says -
Data that has integrity is identically maintained during any operation (such as transfer, storage or retrieval). Put simply in business terms, data integrity is the assurance that data is consistent, certified and can be reconciled.


Regards,
Dan


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
I agree with -
XML Encryption - This is used for confidentiality purpose only
as Getting Started with XML Security says -
The XML Security standards include XML Digital Signature for integrity and signing solutions, XML Encryption for confidentiality, XML Key Management (XKMS) for public key registration, ...


Regards,
Dan
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
Hi!
Remember that what sets XML encryption apart from, for instance SSL, is that you can select to encrypt selected parts of an XML fragment.
This enables intermediaries to process (other) parts of, for instance, a SOAP message without having to be able to decrypt the encrypted parts.
Messages can be forwarded through any number of intermediaries and even stored before finally reaching the receiver which is the only party in the chain able to decrypt the encrypted part.

With SSL, a receiver must decrypt the entire package before being able to do anything with it. Also, encryption is negotiated between two nodes which cannot have any intermediaries.
Best wishes!


My free books and tutorials: http://www.slideshare.net/krizsan
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
Hi again!
Regarding canonicalization:
The following two XML fragments convey identical information while not being character-by-character identical:



So we can agree that despite the XML fragments not being identical, they convey the exact same information.
Then it is logical that they should both result in, for instance, the same XML signature.
In order to be able to calculate a correct, matching, signature for both the XML fragments they need to be processed first. This is canonicalization - a normalization of an XML fragment, prior to, as in our case, the calculation of an XML signature. Canonicalization is performed in order to ignore differences in namespace prefixes, namespace prefix declarations etc when calculating the XML signature.
Hope this makes things more clear!
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Kumar,

About -
2) XML Signature - This is used for Message integrity, authenticity and Non-repudiation.


Just came across a nice article, which says -

XML Signature finds multiple uses for Web Services security. When used alone, it provides data integrity. When linked to the signer’s identity, it provides nonrepudiation of data content. In addition, it can be used for authentication. When SOAP routing occurs, it can be used for workflow.


Regards,
Dan


Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Kumar,

About -

WS-Security implements the above two features using X509 certificates.



WS-Security says -

The specification allows a variety of signature formats, encryptions algorithms and multiple trust domains, and is open to various security token models, such as:

- X.509 certificates
- Kerberos tickets
- UserID/Password credentials
- SAML-Assertion
- Custom defined token
- The token formats and semantics are defined in the associated profile documents.


Interestingly, UserID/Password credentials is there as it has been for decades.


Regards,
Dan
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Kumar,

Thank you for all these questions!

About -
7) Is there any recommended order of applying XML signature and XML encryption. I'm thinking Encryption first and Signing next. Please share your thoughts.


Very interesting question. I think that in many cases, using only one of them is sufficient. XML Signature and Encryption Combinations says -

Although XML Signature and XML Encryption technologies allow flexible combinations, it is the application requirements that should guide the selection of what particular combination should be used. If the requirement is to protect the message with data integrity, authentication and confidentiality, the best combination is to first sign the message and then encrypt the signed message and the signature. If the identity of the signer needs to be revealed for some processing, leave out the signature from encryption.

Technically, it is possible to first encrypt the message and then sign it. However, this is less desirable than encrypting a signed message, for this does not allow encryption of the signature itself. Also, in some applications, signing encrypted data may not provide adequate psychological assurance that the signer knows what has been signed.


Regards,
Dan
Kumar Raja
Ranch Hand

Joined: Mar 18, 2010
Posts: 516
    
    2

Thank you Dan and Ivan.
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
About
6) In typical situations, SAML is used for Identity management for controlling single sign on, but can use XACML to take access decision making.


Makes perfect sense. SAML 2.0 profile of XACML v2.0 says -

This profile defines how to use SAML 2.0 to protect, transport, and request XACML schema
instances and other information needed by an XACML implementation.
There are 6 types of queries and statements used in this profile:
1. AttributeQuery - A standard SAML Request used for requesting one or more attributes from an
Attribute Authority.
2. AttributeStatement - A standard SAML Statement that contains one or more attributes. This
statement may be used in a SAML Response from an Attribute Authority, or it may be used in a
SAML Assertion as a format for storing attributes in an Attribute Repository.
3. XACMLPolicyQuery - A SAML Request extension, defined in this profile. It is used for
requesting one or more policies from a Policy Administration Point.
4. XACMLPolicyStatement - A SAML Statement extension, defined in this profile. It may be used
in a SAML Response from a Policy Administration Point, or it may be used in a SAML
Assertion as a format for storing policies in a Policy Repository.
5. XACMLAuthzDecisionQuery - A SAML Request extension, defined in this profile. It is used by
a PEP to request an authorization decision from an XACML PDP.
6. XACMLAuthzDecisionStatement - A SAML Statement extension, defined in this profile. It may
be used in a SAML Response from an XACML PDP. It might also be used in a SAML
Assertion that is used as a credential, but this is not part of the currently defined XACML use
model.


Regards,
Dan
Kumar Raja
Ranch Hand

Joined: Mar 18, 2010
Posts: 516
    
    2

Hi All,

I thought of reopening the post, as my question is related to the topic, instead of starting a new one. I had already asked this question, but I'm still not clear on XML Signature.

I was reading through a very nice article and the author mentioned as


In the structure above, SignedInfo is a mandatory element since it is the element that is actually signed. That is, if you sign a document in XML Signature, the signature is not generated over the document's digest directly, but over the SignedInfo element (which contains the digest).


My question, when we need to sign the digest of the document, why the specs says to create the digest of the signedinfo, instead of actual document.

Also, in that article, author has also demonstrated with the help of examples for Enveloped, Enveloping and detached type of signatures. So for eg, if we are sending a SOAP request, I believe, that signed document along with signature would become the part of SOAP body.

If using Enveloped Signature, the Signature elements goes with in the singed document. In this case, the xsd of the document should actually consider including signature element definition in the actual document xsd. If not, at the receiving end, XML validation may fail. Is not that correct?
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Kumar Raja wrote: If using Enveloped Signature, the Signature elements goes with in the singed document. In this case, the xsd of the document should actually consider including signature element definition in the actual document xsd. If not, at the receiving end, XML validation may fail. Is not that correct?


I think that the receiving end can validate the xml after the signatures are being undone.

Regards,
Dan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question on XML Signature
 
Similar Threads
XML Signature - why not Enveloping Signatures for SOAP Messages?
Signing XML and Canonicalization
Signing & Verify XML Document
Mechanism type DOM not available
Consumer + intermediary + Provider = digest value mismatch