Exception when creating the signature using OpenSAML lib

[Brent Putman]

On 11/1/12 1:48 PM, Yaowen Tu wrote:
> Hi Brent,
>
> In order to better investigate the problem, I have simplified my code
> into a single class. Attached is the code that produce the same error.
> It has everything. I am using OpenSAML 2.5.3. If possible, could you
> please take a look?

Yes. You never mentioned before that you were loading the metadata via a
MetadataProvider.  You can't validate the signature on an
EntityDescriptor obtained from a MetadataProvider like that.  For
efficiency reasons, our MetadataProvider impls drop the cached DOM (and
on the SignatureImpl, also the Apache XMLSignature instance) on the
metadata document after they load it and all filters are processed. So
once it's loaded, there's no more DOM under the XMLObject tree and you
can't perform any operations which require the DOM to be there, which
includes signature validation.

In order to validate the signature on metadata loaded via a
MetadataProvider, you must supply to the MetadataProvider an instance of
the MetadataFilter which is designed for this purpose:
org.opensaml.saml2.metadata.provider.SignatureValidationFilter.  It
takes as input an instance of SignatureTrustEngine, which I mentioned
before.  There's probably some unit tests which illustrate how to use this.

Otherwise, the rest of the code looks fine.  For example, assuming the
keys are correct and so forth, if you just used the ParserPool to parse
the XML into DOM and unmarshalled it to an EntityDescriptor, the
signature validation as you have it ought to work fine.


>
> Regarding the other question,  if I understand correctly, you said
> suppose the key to sign the metadata is the same as the one used for
> SAML operations, then we need to use X.509 Cert + PKIX to verify the
> key, is that correct? I am a little confused. I thought no matter
> whether we use the same key or not, we still need to trust the key
> used to sign the metadata either by PKIX or other ways. 

Yes, and one major goal of metadata is to establish that trust for the
SAML keys.  If you use the same key, then you are back to square one in
that you have to find some other mechanism to use to establish trust of
that key.  One obvious way is to use PKIX and trust anchors and so
forth.  Another way is to find some other secure channel to distribute
the key to consumers - but if you had that capability, then a lot of the
reason for distributing signed metadata goes away.  And of course,
instead of just distributing the signing key securely, you could have
just distributed the metadata itself...


> After we verify the signature of the metadata, then we know everything
> in the metadata is trusted, then we don't care if the key used for
> SAML operation is the same as the key for signature, we just use it. 

Correct.  And there's nothing technically wrong with using the same
key.  The issue is: how do you go about establishing trust of the
signing key?  You have to solve that correctly for any secure real-world
deployment.