Decryption config

[Cantor, Scott]

On 5/27/14, 6:34 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>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...

Right, I'm trying to work out a practical way to do this without requiring
all kinds of advanced configuration. My straw man is to define a pair of
credentials, a primary and a secondary, and use properties so that by
default they point to the same keypair, but can be adjusted via property
to point to separate ones.

Then I was planning to wire both into a chain resolver so that the IdP
will try to decrypt with both. For rollover, you wire in a second key as
the primary, move the primary to the secondary, and then publish metadata
with the new primary instead of the old one. Once that propagates, you
pull the old primary (now the secondary).

Ideally that's all done via a few properties and no Spring config.

I'd really like to conditionally wire in the secondary instead of using
the duplicate trick, maybe I can do that with Spring expressions somehow.
In practice it doesn't matter too much, it just makes failure a little
more expensive.

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

Ok, that's what I hadn't found yet.

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

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

That was where I was getting lost, I couldn't figure out what they'd be
doing just pulling from KeyInfo without a private or secret key loaded.

-- Scott