Decryption config

[Brent Putman]

On 5/27/14 7:33 PM, Cantor, Scott wrote:
>> 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.
> Ok, that's why I'm concerned about hiding a lot of this, it's too detailed
> for a user.
>
>

Actually, I just realized that doing the chaining that way will cause
duplicates, and therefore unnecessary processing, due to the static
resolver being called potentially many times (once for each PublicKey
and key name seen from the resolved KeyInfo).  What I think we actually
want is:  the KeyInfoCredentialResolver wired into the
DecryptionConfiguration would be a chaining one: the first member would
be the LocalKeyInfo- one I was describing, and the second a
StaticKeyInfo- one.  The local CredentialResolver wired to the
LocalKeyInfo- one would just then be a plain
CollectionCredentialResolver.  You'd presumably just inject the same
list/set of Credentials into both the StaticKeyInfo- and Collection-
resolvers.

However, I just noticed that we don't actually have a
ChainingKeyInfoCredentialResolver.  I'll work on that tomorrow.  It's
non-trivial code b/c of all the Iterable/Iterator stuff, in order to do
the iteration in an efficient and lazy fashion.  But I can just copy the
existing ChainingCredentialResolver, or maybe see if it can just be
subclassed, with narrowing the return type.

Also looks like the latter needs to be updated anyway to be more
Spring-friendly.  It current uses a mutable List<CredentialResolver>
getResolverChain(), rather than setter or constructor injection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140527/a3127141/attachment-0001.html