Fixes#1304, if we want to be harsh.
However, I think if it was the user's intention to pass two certs, and
the second one couldn't be read, that shouldn't just disappear. After
all, when attempting to login later, that might fail because the
expected IdP cert data isn't there.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Notice this when inspecting the code coverage results. For some
reason this test wasn't triggering the bad status code path, maybe
due to signature validation. Removing the comment fixed the code
coverage.
Introduces SAML tests which execute full response processing and
compare user attributes. tesdata now includes a full, self-signed
CA and documents signed using xmlsec1.
Adds deprication notices to existing tests, but don't remove them
since they still provide coverage.
When a SAML response provided multiple Assertion elements, only the
first one is checked for a valid signature. If the Assertion is
verified, the original Assertion is removed and the canonicalized
version is prepended to the Response. However, if there were
multiple assertions, the second assertion could end up first in the
list of Assertions, even if it was unsigned.
For example this:
<Response>
<!--
Response unsigned. According to SAML spec must check
assertion signature.
-->
<Assertion>
<Signature>
<!-- Correrctly signed assertion -->
</Signature>
</Assertion>
<Assertion>
<!-- Unsigned assertion inserted by attacker-->
</Assertion>
</Response>
could be verified then re-ordered to the following:
<Response>
<!--
Response unsigned. According to SAML spec must check
assertion signature.
-->
<Assertion>
<!-- Unsigned assertion inserted by attacker-->
</Assertion>
<Assertion>
<!-- Canonicalized, correrctly signed assertion -->
</Assertion>
</Response>
Fix this by removing all unverified child elements of the Response,
not just the original assertion.
* Improve Order of Namespace Declarations and Attributes in Canonical XML. This is related to an issue in goxmldsig for which I created an [pull request](https://github.com/russellhaering/goxmldsig/pull/17).
* Do not compress the AuthnRequest if `HTTP-POST` binding is used.
* SAML Response is valid if the Message and/or the Assertion is signed.
* Add `AssertionConsumerServiceURL` to `AuthnRequest`
* Validate Status on the Response
* Validate Conditions on the Assertion
* Validation SubjectConfirmation on the Subject
