Decryption config

[Brent Putman]

On 5/27/14 5:49 PM, Cantor, Scott wrote:
> I'm working on the default security configs again.
>
> I'm a little confused about what I would need to do to supply the IdP's
> decryption keys into the configuration, and how that aligns with the
> defaults in the library.

Yeah, I was thinking about this the other day, anticipating that you
were going to get to this soon.  We never had to support decryption
cases in the v2 IdP...

>
> I was thinking I should just supply my own instance of
> org.opensaml.xmlsec.keyinfo.impl.CollectionKeyInfoCredentialResolver to
> supply all the keys configured locally,

Yes, you *could* do that, or the Static- one.  Those would work, but...



>  but that seems to bypass all of
> the KeyInfo resolution behavior in the default resolver that the library
> configures. 

By that I assume you mean that it ignores any KeyInfo hints in for
example the EncryptedKey/KeyInfo, to optimize which keys it tries.  Right...

So for that, I have the
org.opensaml.xmlsec.keyinfo.impl.LocalKeyInfoCredentialResolver.  AFAIK
we've never used that at all, even though it's been in the library since
2.0.  But what it does is extend the
BasicProviderKeyInfoCredentialResolver with additional logic and a
supplied local CredentialResolver that has access to local creds (with
PrivateKey or SecretKey).

It's literally untested unfortunately (as in no unit tests and no real
world testing as far as I remember), but the internal logic is pretty
simple, so not much to go wrong.  I'll work on testing it, but if you
want to just give it a try, that would be a decent smoke test that it's
not horribly messed up.  There's some decent Javadocs on it which
explains what it does in more detail.

For wiring the config, for the standard key transport case, you'd wire
that as the KEKKeyInfoCredentialResolver.  The
DataKeyInfoCredentialResolver would actually be unused here for the
standard SAML cases, etc, and I think can just be null.  (Btw, I have a
TODO to harmonize some of the encryption/decryption config and params
names vis-a-vis "KEK", "key transport" and "key encryption".  With the
new API + old API, I think it's now a little confusing...)

As far as the local CredentialResolver you supply to the above:  a
CollectionCredentialResolver would be the best, since it supports
filtering the results by the criteria passed (in this case
PublicKeyCriterion and KeyNameCriterion).  However, since KeyInfo is
optional, it might be prudent to actually configure in a
ChainingCredentialResolver, with a Collection- one as the first member
and a Static- one as the second.   That way you get KeyInfo hint
optimization, but also fall back to trying all local creds if hinting
doesn't work or doesn't resolve anything.

I just realized that it probably makes no sense to include any
KeyInfoCredentialResolvers in the default library
DecryptionConfiguration.  Those have to have access to local creds and
by definition the library default ones don't.  Don't know what I was
thinking there.  I'll pull them (unless I remember a reason not to).


> With the SP, it sort of merges the two to use the KeyInfo to
> optimize the local lookup, is there something similar I should be doing
> here?


Yeah, that's basically what this Local- resolver does as well.


>
> Also, I probably need to override the default EncryptedKeyResolver to
> include the SAML-based one in the chain, right?

Yes.  Since the default config bootstrap happens via xmlsec-impl, it
can't do the SAML one, since it's not in the dependency scope.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140527/013a2d0d/attachment.html