IdP credentials for delegation Assertion signature validation
Brent Putman
putmanb at georgetown.edu
Thu Aug 20 22:40:04 EDT 2015
On 8/20/15 10:26 PM, Cantor, Scott wrote:
> On 8/20/15, 10:23 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>> Maybe something on the profile config bean could work. Because of the reloadability I'm assuming you don't mean inject credential beans directly, but rather something that exposes them or uses them.
> Well, I was responding to the original thread and I meant injecting them directly because the profile config beans and the credential beans are currently both inside the RP service context.
Oh, right, they're in the same context, I forgot. That makes sense.
>
> I realize that in theory, yes, you can define credentials in disconnected places in that configuration and attach them directly to things, but in practice they'd be in credentials.xml and referenced where needed.
>
> I don't think it's a bad idea to have a credential "service", but I don't know that it's 100% required.
I'll think about that. That aspect might be easier, but as I said,
right now the components assume they are going to be wired in the flow
beans. I don't "resolve" the Assertion validator or its constituent
SignatureTrustEngine for example. To use creds injected on the profile
config I think I'd have to switch some things to be constructed on the
fly at runtime based on the injected creds. So that part would be more
complex.
Actually there's also the issue of *which* profile config. I think it's
also back to the "to whom did I sign" question. Unless we just injected
the all the creds on all the profile configs (on the abstract one, etc).
Then we could pick anyone (e.g. the one already resolved for the SAML
requester). But that sort of doesn't feel right.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150820/5c750ce2/attachment.html>
More information about the dev
mailing list