Exception when creating the signature using OpenSAML lib

Yaowen Tu yaowen.tu at gmail.com
Thu Nov 1 18:55:59 EDT 2012


Awesome. Thanks for you clarification.

I am currently stuck with the SignatureTrustEngine. It seems to be a
chicken egg problem. Now I am trying to verify the signature of a metadata,
but I need to get the key from the metadata first. Please see the code
below:

        //Get file from file system.
        FilesystemResource resource = new FilesystemResource( metadataFile
);

        ResourceBackedMetadataProvider metadataProvider = new
ResourceBackedMetadataProvider( new Timer(), resource );
        metadataProvider.setParserPool( new BasicParserPool() );
        metadataProvider.setRequireValidMetadata( true );


        MetadataCredentialResolverFactory mcrFactory =
MetadataCredentialResolverFactory.getFactory();
        MetadataCredentialResolver credResolver = mcrFactory.getInstance(
metadataProvider );//Here it will fail, becuase the "metadataProvider" has
not been initialized. I have to load the metadata without verifying it
first to get the credential, then load it again in order to verify the
signature.

        SignatureTrustEngine trustEngine = new
ExplicitKeySignatureTrustEngine(credResolver,

Configuration.getGlobalSecurityConfiguration().getDefaultKeyInfoCredentialResolver());

        SignatureValidationFilter filter = new
SignatureValidationFilter(trustEngine);
        metadataProvider.setMetadataFilter(filter);
        metadataProvider.initialize();

Instead of using MetadataCredentialResolver, it has
StaticKeyInfoCredentialResolver, but still the same problem, I need to get
the credential first.

I understand that this question is related to what we have just discussed.
Using the key inside the signature is not secure. We should either use PKI
or other secure channel for example get the key directly. If I want to use
PKI, could you show me some sample code if there is any? or give me some
hints about what I should do? I didn't find much information in wiki.


Thanks,
Yaowen


On Thu, Nov 1, 2012 at 2:56 PM, Brent Putman <putmanb at georgetown.edu> wrote:

>
> On 11/1/12 5:28 PM, Yaowen Tu wrote:
> >
> >
> > For the key, I think I understand it, but I may need some
> > clarification. My opinion is metadata is used to provide some
> > information to consumer including SAML keys.
>
> Yes.
>
> > How we can trust the metadata is to verify the signature. We need to
> > use some key to verify the signature. Then the question result into:
> > how do we trust the key used for signature. As you said, we can use
> > PKIX to verify the certificate and the key, or we can find some secure
> > channel to distribute the key. As soon as we trust the key used for
> > signature, we are done.
>
> Yes.
>
>
> > It really doesn't matter what key we would use for SAML operations.
>
> No, it doesn't matter, as long as the key is present  within a
> KeyDescriptor under the correct role and protocol in the metadata and
> with the correct usage specifier.
>
>
> > We implicitly trust the SAML key because we already verified signature
> > and trusted metadata, so we trust everything in the metadata including
> > SAML key.
>
> Yes.  Note that signed SAML metadata containing keys is essentially
> another form of public key "infrastructure" (without all the actual
> infrastructure), in that it is cryptographically binding one or more
> keys to an entity's identifier and other info about the entity.  Which
> is exactly what an X.509 certificate does.
>
>
>
> > So my point is that there is no technical reason why we cannot use the
> > same key for signature and SAML operations. My I correct?
>
> As I said earlier, there is no technical reason you can't do this.  You
> just have to decide on a trust model for the metadata signing key.
>
> --
> 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/db2b5b0a/attachment-0001.html 


More information about the dev mailing list