SAML Validation Signature Check appears to let modified assertions through

Not applicable

We have a validate saml assertion policy configured as in the documentation and while it appears to work when a saml assertion is indeed valid (meaning the assertion text should match up with the signature having not been tampered with) it also lets assertions through that HAVE been tampered with. For example, I'm able to extend the saml validity time by simply changing the date and time in the NotOnOrAfter attribute of the saml:Contitions element. I've also made other changes to a previously "signed" saml assertion and the assertion passes through the policy assigned the typcial SAML variables and so on.

Are there undocumented configuration parameters that are necessary? Could this be a bug?

We've followed the documentation outlined here - http://apigee.com/docs/api-services/reference/saml...

Solved Solved
2 6 1,230
1 ACCEPTED SOLUTION

A further comment - I experimented a little more with some variations. Here's what I found.

If the saml assertion is contained within a Saml response, and the signedinfo is the Saml Response element, then... validating the saml assertion does not also validate the signature on the response.

What this means is that you can modify the contents of the saml assertion, and the policy will not throw a fault.

Perhaps this is what you experienced.

I believe this behavior is not only counter-intuitive, but also a security bug.


In more detail, the SAML spec allows:

  1. the signature to be applied to the Assertion element.
  2. the signature to be applied to an element that contains the Assertion element, such as saml2p:Response.

The VerifySAMLAssertion policy in Apigee Edge is verifying the signature only in the first case - if the Signature is applied to the Assertion element.

The policy should also verify the signature in the latter case. In fact the policy should handle the Assertion in that case just as if it alone had been signed. See section 5.3 of the saml 2.0 core spec. It's a bug that it silently does not verify the signature.

ref: b/67165195

EDIT: This bug has long ago been fixed. If you are using OPDK 4.50 or any current version of Apigee, this bug no longer exists. BUT, you need to modify your ValidateSAMLAssertion policy to use new configuration elements : AssertionXPath and SignedElementXPath.  See the documentation for details.

View solution in original post

6 REPLIES 6

Not applicable

@Vinit Mehta - Can you help with this ?

After our brief discussion during the Apigee Conference last week, I feel you could help us with correcting this SAML assertion. (Else please suggest a contact point to take this up offline). We are going to prod - soon. We need this resolved.

,

Hi @John Cartwright

Can you please provide:

  1. an example, valid SAML Assertion
  2. Your ValidateSAMLAssertion policy configuration

I have just tried this on my own private cloud installation of Apigee Edge v 4.15.07. I modified the NotOnOrAfter attribute in the Conditions element. When I passed that assertion into the ValidateSAMLAssertion policy, I received, as expected, a fault:

{
  "fault": {
    "faultstring": "ValidateSAMLAssertion[SAML-Validate-1]: Error during signature validation",
    "detail": {
      "errorcode": "steps.saml.ERROR_VALIDATING_SIGNATURE"
    }
  }
}

A further comment - I experimented a little more with some variations. Here's what I found.

If the saml assertion is contained within a Saml response, and the signedinfo is the Saml Response element, then... validating the saml assertion does not also validate the signature on the response.

What this means is that you can modify the contents of the saml assertion, and the policy will not throw a fault.

Perhaps this is what you experienced.

I believe this behavior is not only counter-intuitive, but also a security bug.


In more detail, the SAML spec allows:

  1. the signature to be applied to the Assertion element.
  2. the signature to be applied to an element that contains the Assertion element, such as saml2p:Response.

The VerifySAMLAssertion policy in Apigee Edge is verifying the signature only in the first case - if the Signature is applied to the Assertion element.

The policy should also verify the signature in the latter case. In fact the policy should handle the Assertion in that case just as if it alone had been signed. See section 5.3 of the saml 2.0 core spec. It's a bug that it silently does not verify the signature.

ref: b/67165195

EDIT: This bug has long ago been fixed. If you are using OPDK 4.50 or any current version of Apigee, this bug no longer exists. BUT, you need to modify your ValidateSAMLAssertion policy to use new configuration elements : AssertionXPath and SignedElementXPath.  See the documentation for details.

According to the SAML Signature Reference element it's the Assertion - minus the Signature element - that is getting signed, not the whole SAML response.

Hi John - I think you are saying that the SAML spec says that the Assertion is the thing being signed. The SAML spec allows this and also allows the case in which the signature is applied to an element (such as a saml2p:Response) that contains an Assertion. In other words, it need not be ONLY the Assertion that is signed, it could be a parent element that gets signed. It could be the entire Saml Response. And in that case, the Assertion should be interpreted just as if it alone had been signed. See section 5.3 of the saml 2.0 core spec.

Can you show us your case? Can you provide your complete SAML doc which contains the Assertion, as well as the Signature and SignedInfo elements?

Hi dino, could you please tell me what are the validation about the signature made by the policy Validate Assertion?, i created this https://community.apigee.com/questions/15829/saml-validate-doesnt-seem-to-work.html