Exception when validating the signature of the assertion
Yaowen Tu
yaowen.tu at gmail.com
Tue Nov 6 17:28:56 EST 2012
Thanks Brent. There is another general signature related question I want to
know. If I understand correctly, the mechanism work in this way:
1. On IdP side, it creates an Assertion, and generates a signature based on
this assertion
2. IdP send the Assertion and signature to SP side.
3. When SP tries to validate the signature, theoretically it needs to:
a. make sure the signature is generated by the private key of the
IdP
b. make sure the message is not modified by comparing the digest
value of the assertion and decrypted signature.
The method validateSignature(Signature signature, Credential
validatingCredential) seems to only do the step (a), could you please tell
me where and how we do step (b)? Maybe the Signature object contains some
extra information than I imagined?
Thanks,
Yaowen
On Tue, Nov 6, 2012 at 12:11 PM, Brent Putman <putmanb at georgetown.edu>wrote:
>
> On 11/6/12 2:30 PM, Yaowen Tu wrote:
> > Hi,
> >
> > When I try to validate the signature of a decrypted assertion, I got
> > the following exception:
> >
> > Caused by: org.opensaml.xml.validation.ValidationException: Apache
> > xmlsec IdResolver could not resolve the Element for id reference:
> > _83f4c0d593d29a106d35d59acc15da2b
> > at
> >
> org.opensaml.security.SAMLSignatureProfileValidator.validateReferenceURI(SAMLSignatureProfileValidator.java:153)
> > at
> >
> org.opensaml.security.SAMLSignatureProfileValidator.validateSignatureImpl(SAMLSignatureProfileValidator.java:84)
> > at
> >
> org.opensaml.security.SAMLSignatureProfileValidator.validate(SAMLSignatureProfileValidator.java:56)
> >
>
>
> This is basically the issue that is highlighted in the big red warning
> box directly underneath this spot in the wiki:
>
>
> https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaXMLEncryption#OSTwoUserManJavaXMLEncryption-CreateaSAML2Decrypter
>
> For the details, please see the Javadocs as noted there.
>
>
>
> > My code is:
> > //The getAssertion method will decrypt the assertion from
> > the response
> > Assertion assertion = getAssertion( response );
> >
> > if( assertion.isSigned() )
> > {
> > // Now we must validate the signature of the assertion
> > Signature signatureToValidate = assertion.getSignature();
> > // Now try to validate. Throw exception if not valid.
> > super.validateSignature( signatureToValidate,
> > validatingCredential);
> > }
> >
> > public void validateSignature(Signature signature, Credential
> > validatingCredential) throws ValidationException
> > {
> > SAMLSignatureProfileValidator profileValidator = new
> > SAMLSignatureProfileValidator();
> > profileValidator.validate( signature );
> >
> > SignatureValidator signatureValidator = new
> > SignatureValidator( validatingCredential );
> > signatureValidator.validate( signature );
> > }
> >
>
>
> That looks fine, at least as far as mechanically validating the
> signature (still need to establish trust of the validation key, but
> perhaps you are doing that elsewhere). The issue isn't with how you're
> validating the signature, but rather with how it is being decrypted and
> some things that happen at the DOM level. The info I reference above
> above should explain why.
>
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20121106/1395b212/attachment.html
More information about the dev
mailing list