OpenSAML user discussion

[Brent Putman <>]

Mike Klein wrote:
> Grabbing a public cert from a keystore can be done in 3 lines of code or
> so...this isn't an issue. OpenSAML won't provide you an uber-keystore
> concept or anything I think so you'll need to load and cache them yourself.
>   


To add to what Scott said, for the non-trivial use cases (and even for
those) you can use a CredentialResolver to resolve Credentials which
contain keys and related information for particular purposes (e.g.
signature signing/verification, encryption/decryption and SSL/TLS). 
Resolution is based on a set of CredentialCriteria that is specified to
the resolver.  The store for credential information used by a particular
resolver impl could be simple PEM-encoded cert/key files, Java keystore,
custom config file, etc.  We have, or will have, several implementations
for common requirements.

For SAML use cases in particular, you might often be retrieving public
signature verification and encryption keys for remote peers from an
instance of SAML metadata.  Check out the MetadataCredentialResolver and
the MetadataProviders in the OpenSAML 2 library.

You might also for example be sent a signature verification key in the
message via the ds:KeyInfo element.  See the KeyInfoCredentialResolver
(which is complex and has many uses because KeyInfo is pervasive in the
Signature and Encryption specs, as well as being used within SAML
metadata KeyDescriptors).  In this case you need to establish whether
you trust the received key as wielded by the signing entity acting in
the relevant role.  That's what the TrustEngines are for, trusting a
particular type of token (e.g. Signature) - and which are being heavily
refactored at the moment.   If you already had the key/cert in your set
of trusted keys for the signing entity, that's easy (just a straight
matching operation).  If not, you need to establish the trust based on
taking other information into account, for example, via PKIX validation
using trusted certificate chains and CRL's, etc. 


So yeah, we do that.  :-)

In fact a (scarily?) large part of the XMLTooling codebase (and OpenSAML
and other things that sit on top) are related to these various
security-related requirements: credentials, key/credential resolution,
XML Signature & Encryption support (esp. KeyInfo processing), TLS
support and trust evaluation.


--Brent