<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 5/27/14 5:49 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CFAA809B.4E9CE%25cantor.2@osu.edu" type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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...<br>
<br>
<blockquote cite="mid:CFAA809B.4E9CE%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I was thinking I should just supply my own instance of
org.opensaml.xmlsec.keyinfo.impl.CollectionKeyInfoCredentialResolver to
supply all the keys configured locally,</pre>
</blockquote>
<br>
Yes, you *could* do that, or the Static- one. Those would work,
but... <br>
<br>
<br>
<br>
<blockquote cite="mid:CFAA809B.4E9CE%25cantor.2@osu.edu" type="cite">
<pre wrap=""> but that seems to bypass all of
the KeyInfo resolution behavior in the default resolver that the library
configures. </pre>
</blockquote>
<br>
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...<br>
<br>
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).<br>
<br>
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.<br>
<br>
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...)<br>
<br>
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.<br>
<br>
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).<br>
<br>
<br>
<blockquote cite="mid:CFAA809B.4E9CE%25cantor.2@osu.edu" type="cite">
<pre wrap="">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?</pre>
</blockquote>
<br>
<br>
Yeah, that's basically what this Local- resolver does as well.<br>
<br>
<br>
<blockquote cite="mid:CFAA809B.4E9CE%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Also, I probably need to override the default EncryptedKeyResolver to
include the SAML-based one in the chain, right?</pre>
</blockquote>
<br>
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.<br>
</body>
</html>