Exception when creating the signature using OpenSAML lib

[Yaowen Tu]

Sorry, I missed the metadata file. Attached is the one also used in
Shibboleth unit test. I also tried to run the test against other metadata,
still the same error.

Yaowen


On Thu, Nov 1, 2012 at 10:48 AM, Yaowen Tu <yaowen.tu at gmail.com> 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?
>
> 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/384932e7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-metadata.xml
Type: text/xml
Size: 5439 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20121101/384932e7/attachment-0001.xml