IdP credentials for delegation Assertion signature validation

[Cantor, Scott]

On 8/19/15, 11:59 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>So, looking for input here.  Should we look at (perhaps redundantly with the RPCR) loading credentials.xml in the root context to get at them as visible beans?  Or is there some way to leverage what's already in the RPCR? I guess the (horribly complex) way to do the latter would be to see to whom we issued the Assertion and then attempt to resolve the creds via the RPCR that would have been candidates for signing.  Or something like that.  Not sure that that even works.

I was going to suggest that, but the problem with that approach is it won't consistently give you the same guaranteed answer as you got when you issued the assertion. It's possible to implement pretty arbitrary predicates to determine the RP config to use, and if those predicates act on data that's only present when the request is originally made and not present on the subsequent call, it won't work. So, no, I don't think it works.

>But definitely feels like overkill, esp since the number of creds here is very small (by default 1).  So I was thinking of keeping it simple and just trying all the IdP creds that are configured.

If you recall, we had discussed the notion of creating some kind of shared service context for "security stuff", but it was never very clear in my mind what it would be used for so I tabled it.

One possibility, maybe not ideal, would be to add this to the profile configuration bean you're leveraging. Normally we don't expose the credentials directly from those config beans since we use more complex logic to derive the signing key, but it wouldn't really be that hard to inject them into a profile config bean.

-- Scott