WS-Security SAML Token & SAML Session Ticket implementation concerns (Legacy_Onyx KB Id: 257805)
Article ID: 54885
Updated On:
Products
Issue/Introduction
Description:
This issue has been opened by Russi ([email protected]):
I have several questions that I don't seem to be able to get answers for from the security ream or product management. I'd like to obtain exact and official CA responses to these questions. Please help.
1) According to WS-Security standard, when SAML token is used for web-services authentication, SAML Assertion may contain multiple subject confirmation statements (for example, holder-of-the-key & sender vouches could both be specified). For successful authentication it would be sufficient that at least one of the provided subject confirmation methods is successful.
Question: It is not clear from CA's documentation how SOA Security Manager / TransactionMinder implements WS-Security specification from this point of view. I have a feeling that it includes a single confirmation statement per SAML assertion. Is this a correct assumption?
2) Holder-of-the-key implementation (again from the standard): must demonstrate knowledge of ANY key identified in a holder-of-key SubjectConfirmation element. Specifically, saml2:KeyInfoConfirmationDataType, that includes 1 or more <ds:KeyInfo> elements, can be specified as the xsi:type of the <saml2:SubjectConfirmationData> element. In this case, each <ds:KeyInfo> element identifies a key that may be demonstrated to confirm the assertion. The SubjectConfirmation elements MUST include a <ds:KeyInfo> element that identifies a public or secret key5 that can be used to confirm the identity of the subject. To satisfy the associated confirmation method processing to be performed by the message receiver, the attesting entity MUST demonstrate knowledge of the confirmation key. The attesting entity MAY accomplish this by using the confirmation key to sign content within the message and by including the resulting <ds:Signature> element in the <wsse:Security> header.
Question: How exactly does TxM / SOA Security Manager implement this? It is unclear from the CA documentation which part of the message may be signed. I am worried that in the case of our implementation of this standard we are talking about the entire XML document. This is because most customers use ESBs that inject additional information into the XML / SOAP documents and if the signature were related to the whole document request sent by the client, in this case the digital signature to be used to validate the holder-of-the-key would no longer be valid. I should be able to decide which content of the message I want to sign. It does not seem to me that I am able to do this with TxM. Am I wrong?
3) Same question in relation to the digital signature application to sender-vouches... Can I decide which part of the message content to sign? It does not seem to me.
4) As far as the SAML Session Ticket usage is concerned within TxM / SOA Security Manager, I am concerned about the following statement in the Policy Design Guide. It is my understanding that I CANNOT request a signature ONLY on the SAML assertion (am I correct?):
How Signing Assertions Affects SAML Session Ticket Authentication
If the TXM_Sign_Assertion variable was used to sign an assertion, the SAML Session Ticket authentication scheme behaves as follows:
a) If the authentication scheme does not require a signed document, all signatures are ignored.
b) If the authentication scheme does require a signed document:
- The document must be signed and the signature must be valid.
- If the assertion is signed, it must also be valid.
- If only the assertion is signed but the document is not, the document is invalid.
Thank you very much in advance
Solution:
Here are engineering's responses to your questions.
1) According to WS-Security standard, when SAML token is used for web-services authentication, SAML Assertion may contain multiple subject confirmation statements (for example, holder-of-the-key & sender vouches could both be specified). For successful authentication it would be sufficient that at least one of the provided subject confirmation methods is successful.
Question: It is not clear from CA's documentation how SOA Security Manager /TransactionMinder implements WS-Security specification from this point of view. I have a feeling that it includes a single confirmation statement per SAML assertion. Is this a correct assumption?
-----
Answer: We can do multiple SAML subject confirmation statements (and often do, if you look at generating an SVS token). This will authenticate in either HK or SV authentication. So, the answer is: Yes, we do support this.
-----
2) Holder-of-the-key implementation (again from the standard): must demonstrate knowledge of ANY key identified in a holder-of-key SubjectConfirmation element. Specifically, saml2:KeyInfoConfirmationDataType, that includes 1 or more <ds:KeyInfo> elements, can be pecified as the xsi:type of the <saml2:SubjectConfirmationData> element. In this case, each <ds:KeyInfo>element identifies a key that may be demonstrated to confirm the assertion. The SubjectConfirmation elements MUST include a <ds:KeyInfo> element that identifies a public or secret key5 that can be used to confirm the identity of the subject. To satisfy the associated confirmation method processing to be performed by the message receiver, the attesting entity MUST demonstrate knowledge of the confirmation key. The attesting entity MAY accomplish this by using the confirmation key to sign content within the message and by including the resulting <ds:Signature> element in the <wsse:Security> header.
Question: How exactly does TxM / SOA Security Manager implement this? It is unclear from the CA documentation which part of the message may be signed. I am worried that in the case of our implementation of this standard we are talking about the entire XML document. This is because most customers use ESBs that inject additional information into the XML /SOAP documents and if the signature were related to the whole document request sent by the client, in this case the digital signature to be used to validate the holder-of-the-key would no longer be valid. I should be able to decide which content of the message I want to sign. It does not seem to me that I am able to do this with TxM. Am I wrong?
-----
Answer: We check the Holder-of-Key certificate specified in the SAML assertion and compare it to the reference located within the Signature block located as a child under the WS-Security node. It should look like:
<SOAP:Header>
<wsse:Security>
<saml:Assertion>
...
</saml:Assertion>
<dsig:Signature>
...
</dsig:Signature>
</wsse:Security>
</SOAP:Header>
<SOAP:Body>
...
</SOAP:Body>
The references in the signature block can point to anything, although typically it is the SOAP
body. But, all we do with HK authentication is:
1) Verify the certificate in the assertion matches the one referenced in the Signature.
2) Verify the signature is valid
The customer can add any data into the document as long as the above criteria is met.
-----
3) Same question in relation to the digital signature application to sender-vouches... Can I decide which part of the message content to sign?
-----
Answer: No. Sender-vouches has a specific format, which is signed by the policy server/agent. We sign the body and the assertion and make the document immutable. This is by design.
Essentially, you use HK if you want to reuse an assertion and handle the signing yourself. You use SV if you want the policy server to manager your signing for you, but that means you include your payload prior to an SV response.
-----
4) As far as the SAML Session Ticket usage is concerned within TxM / SOA Security Manager, I am concerned about the following statement in the Operations Guide. It is my understanding that I CANNOT request a signature ONLY on the SAML assertion (am I correct?):
How Signing Assertions Affects SAML Session Ticket Authentication
If the TXM_Sign_Assertion variable was used to sign an assertion, the SAML Session Ticket authentication scheme behaves as follows:
- If the authentication scheme does not require a signed document, all signatures are ignored.
- If the authentication scheme does require a signed document:
- The document must be signed and the signature must be valid.
- If the assertion is signed, it must also be valid.
- If only the assertion is signed but the document is not, the document is invalid.
-----
Answer: Currently, your assumption is correct. We only specify an all or nothing policy to signatures in the SAML session ticket. It's a checkbox in the UI, so it is by design. I spoke about this a while ago with a couple people, and it might make sense to modify it, but since is the current expected behavior, there is no plan to enhance the product in this fashion at this time.
Environment
Component: TXMFNC
Feedback
