Exception when creating the signature using OpenSAML lib

[Yaowen Tu]

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?

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. 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. Is there anything wrong?

Thanks,
Yaowen


On Thu, Nov 1, 2012 at 9:30 AM, Brent Putman <putmanb at georgetown.edu> wrote:

>
> 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.
>
> --
> 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/20121101/ee26a145/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestSignature.java
Type: application/octet-stream
Size: 2980 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20121101/ee26a145/attachment.obj