OpenSAML user discussion

[Brent Putman <>]

Massimiliano Masi wrote:
> Hi,
>
> Quoting Brent Putman 
> <>:
>> If you're not obtaining a signing Credential from a CredentialResolver,
>> you can just build a simple credential that wraps a symmetric key or key
>> pair with one of the utility methods in
>> org.opensaml.xml.security.SecurityHelper
>
>
> What is a CredentialResolver?


It's the interface defined here:
org.opensaml.xml.security.credential.CredentialResolver. 
CredentialResolver is the abstraction we use in the OpenSAML stack to
resolve one or more Credentials based on some Criteria specified in a
CriteriaSet.  A typical criteria would be the ID of the entity that owns
a Credential/key. Other criteria might be a key name, a usage indicator
(signing vs. encryption) or a public key itself (for resolving the
corresponding private key).

For example, when you validate a ds:Signature you need to resolve a
verification key (contained within a Credential) if the ds:KeyInfo was
absent or did not contain the verification key by value (i.e. only by
reference via an identifier).  Further, even if it did contain the
verification key by value, you need to establish that you trust that
key, and one way is to resolve a set of trusted Credentials from a
trusted source via a trusted CredentialResolver (e.g. one that uses
trusted SAML 2 metadata - possibly itself signed - as the source of
trusted keys).

In addition to signature verification and trust establishment, you have
similar use cases for resolving keys/Credentials for:

* signing (resolve one of your own keys that's appropriate for the
recipient(s))
* encryption
* decryption
* SSL/TLS



>
> Another question: in the example in Trunk,
> http://svn.middleware.georgetown.edu/view/trunk/test/org/opensaml/saml2/core/SignedAssertionTest.java?revision=1050&view=markup
>
>
> there is this comment:
>
>
>         //TODO verify signature with new trust engine
>
> Is there a new trust engine for opensaml?


Well, the "new" in this case is relative to older
interfaces/implementations that we had.   The security code in OpenSAML
has been through a couple of iterations/refactorings.

The TrustEngine component isn't really "new" per se, it has its origins
in what was previously developed for Shibboleth.  In Shibboleth 2.0 and
OpenSAML 2.0, the trust engines have been moved down from Shibboleth
into the OpenSAML stack (actually most is really in XMLTooling).

Some docs (probably slightly out of date) on the basic trust engine
concept are here in the Shibboleth portion of the wiki:

https://spaces.internet2.edu/display/SHIB/TrustEngine

At some point that will be moved or at least added to in the OpenSAML
docs proper.

--Brent