Exception when creating the signature using OpenSAML lib
Brent Putman
putmanb at georgetown.edu
Thu Nov 1 12:30:12 EDT 2012
On 10/31/12 9:27 PM, Yaowen Tu wrote:
> 1. I am not signing and validating the same instance. I write the
> whole metadata to a file, then in step 2, I load it and validate it.
> So I don't think I am hinting the same issue.
>
Ok, that should bypass any of the kind of problems I had in mind.
> 2. Even if I just load a testing metadata file, for example
> openid-metadata.xml, which you are using in the unit test as well. I
> still see the same error.
Yeah, that's odd. I really don't have an explanation for how an
unmarshalled SignableSAMLObject can have a non-null Signature child, but
that Signature child doesn't have the Apache XMLSignature instance. The
SignatureUnmarshaller doesn't really allow that to happen as far as I
can tell. The answer must lie in something that you haven't told us or
shown us yet, possibly in something that you are doing before the
signature validation takes place and/or in setting up your environment,
and whatever that is has an odd side-effect.
> So maybe my code to validate the signature is wrong?
> Here is my code, which is pretty much same as wiki:
> public void validateSignature(Signature signature, Credential
> validatingCredential) throws ValidationException
> {
> SAMLSignatureProfileValidator profileValidator = new
> SAMLSignatureProfileValidator();
> profileValidator.validate( signature );
>
> SignatureValidator signatureValidator = new
> SignatureValidator( validatingCredential );
> // Now try to validate. Throw exception if not valid.
> signatureValidator.validate( signature );
> }
> For testing, validatingCredential is the one I get under the
> <Signature><KeyInfo> tag. Can you see any problems? Or do you have any
> simple working example that I can look at?
No problems that I can see, that part looks fine. I suspect the problem
is something that you are doing before this.
>
> 3. Regarding this sentence: " The KeyDescriptor/KeyInfo is the
> entity's own key that it uses for SAML purposes, and in the real world
> is very often not the metadata signing key." We are currently in the
> process of developing a Single Sign On product, can you please tell me
> more about why these two keys are very often no the same?
Because it's often the case that the place/entity/actor that publishes
metadata (and so signs it) is not the entity (or entities) whose
metadata is being published. The big example is a federation.
It's not impossible for an entity to sign its own metadata with the same
key it uses for SAML operations, but then you have to deal with the
obvious question of how the trust fabric works. One major function of
metadata is to distribute an entity's key(s), so as to establish the
SAML trust layer; if it signs the metadata with that same key, then how
does the consumer trust that key for purposes of validating the metadata
signature? That's just pushing the trust problem up another layer. One
way is to validate the signature not by having trusted the key
explicitly in advance, but by using X.509 cert + PKIX mechanisms with
trust anchors, and some conventions around how the name(s) in the cert
is bound to the signing entity (e.g its SAML entityID). That's beyond
the scope of this email however.
More information about the dev
mailing list