Exception when creating the signature using OpenSAML lib

[Brent Putman]

On 11/1/12 6:55 PM, Yaowen Tu wrote:
> 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.

No, it's not a chicken and egg problem, and yes, it is related to the
key issue we were discussing.  The trust material must be exchanged out
of band, via some secure channel.

If you are going to go with the explicit key trust mechanism, this means
obtaining the trusted key(s) for validating the signature. If the entity
is signing its own metadata with the same key that it uses for SAML ops,
that of course means obtaining the entity's key.  And if you can do that
securely, you might as well just have obtained the (presumably unsigned)
metadata itself, rather than the signing key. For that reason, this
isn't a terribly useful real-world trust model for the self-signed
metadata case.

If you go the PKIX route (which is more realistic for self-signed
metadata), it means obtaining PKIX validation info (e.g. trust anchor
certificates, the CA cert(s)).


>
> 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.


For the PKIX approach, you'd want to use the PKIXSignatureTrustEngine
impl. There's probably some unit tests for that illustrating its usage. 
But basically you supply to that a PKIXValidationInformationResolver. 
For this case, you'd probably just use the
StaticPKIXValidationInformationResolver.  That would take one or more
instances of PKIXValidationInformation (e.g. the
BasicPKIXValidationInformation impl) containing the trust anchor (CA)
certs that root the PKI of the signing cert.  The Set<String> of trusted
names would be the name(s) that are considered valid to be bound in the
signing cert. It will by default evaluate the full subject DN, the CN
from the subject DN and subject alt names.  For the self-signed metadata
case, it probably makes the most sense for the signing cert to contain
the SAML entityID as a URI subject alt name, and then you supply that
entityID to the resolver as a trusted name.