1) XML Encryption - This is used for confidentiality purpose only - So that nobody would tamper the message in the transit.
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.
as Getting Started with XML Security says -
XML Encryption - This is used for confidentiality purpose only
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, ...
2) XML Signature - This is used for Message integrity, authenticity and Non-repudiation.
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.
WS-Security implements the above two features using X509 certificates.
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
- Custom defined token
- The token formats and semantics are defined in the associated profile documents.
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.
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.
6) In typical situations, SAML is used for Identity management for controlling single sign on, but can use XACML to take access decision making.
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
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
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).
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?