IdP credentials for delegation Assertion signature validation
Brent Putman
putmanb at georgetown.edu
Thu Aug 20 22:32:24 EDT 2015
On 8/20/15 10:05 PM, Cantor, Scott wrote:
> On 8/20/15, 10:00 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>> No, I don't think so. There could be many signing creds and the exact one that was used certainly can't be assumed to be in the default list. It might have been an RP-specific one not specified in the default SecurityConfiguration.
> I'm not sure we necessarily have to make it that complex.
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.
> The intention is that the credentials would be declared in one place, even if they're applied/used in different situations.
Totally agreed, they should all be defined in one place
(conf/credentials.xml). Else insanity ensues.
>> Either way, the thing I guess I would need agreement on is that: in order for this to work, I believe we'd need to assume a new bean structure in conf/credentials.xml. We'd need to have the deployer wrap all the defined signing credentials in a new list, e.g.
> Granted, what I'm suggesting would still have to presume a surrounding structure that's not currently there.
>
> But if you want to do the work of creating a CredentialService, which certainly isn't a bad thing, we probably should migrate everything to that and come up with a way to do that backward-compatibly.
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. Unless we just
made the RP context a child of the CredentialService's context, but I
think that gets hairy, with the reloading and everything. Yikes.
Without that, wouldn't we need to basically inject Credential proxies
into current components? Where the proxy delegates to the
CredentialService.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150820/802e1977/attachment-0001.html>
More information about the dev
mailing list