IdP credentials for delegation Assertion signature validation

[Brent Putman]

On 8/20/15 10:37 PM, Cantor, Scott wrote:
> On 8/20/15, 10:32 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>> I wasn't referring to doing some complex config for delegation.  Just that there can be many SecurityConfiguration instances: the default one and then ones at other levels.  That's already true today. Rod mentioned using just the default one, and that won't work b/c it obviously doesn't necessarily include them all.
> But that isn't necessarily the credentials themselves, just references to them in most cases.

I think you're missing my point there, or I'm missing yours. We can talk
about it tomorrow if necessary.
>
>> The intention is that the credentials would be declared in one place, even if they're applied/used in different situations.
> If that's the case, you don't need a service. Just inject the one collection of public keys into your profile config. No special work needed.

As I said in the note I just sent, that's less complex, but then it
makes the delegation stuff more complex b/c things would have to be
resolved at runtime rather than wired.

>> I was wondering whether we should do something similar for the encryption ones (the single list), just for symmetry.  That seems easy.  If you're suggesting moving all credential usage to be via the CredentialService, that seems more than what I needed.
> I guess I'm not following the suggestion. We'd have to, AFAICT.

No, Rod had floated the idea that conf/credentials.xml could be read and
loaded by both services.  So the existing RP stuff would still have the
creds and would need no changes.  The hypothetical new cred service
would also load them, and expose them in a different way, for a
different purpose.


>> Without that, wouldn't we need to basically inject Credential proxies into current components?  Where the proxy delegates to the CredentialService.
> Yes, and I'm basically trying to avoid all that with a simplifying assumption that we can just inject one collection of keys into the profile config bean, in the existing service/context, and you just read from that in your evaluation of the signature.


I don't want to replace *all* cred usage with a CredentialService and do
proxies (at least right now).  I'm assuming credentials in both
contexts.  With that, I think the CredentialService is far simpler for
the other components to user.  Otherwise I'll have to build a bunch of
resolution stuff to build on the fly and resolve the necessary cred
resolver and signature trust engine.  With a service I can write a cred
resolver impl in about 5 minutes and I'm done.

There are definitely trade-offs here.  Just trying to work through them.