IdP credentials for delegation Assertion signature validation

[Brent Putman]

On 8/20/15 2:39 PM, Cantor, Scott wrote:
> 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:
>> 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. 
> 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.

Yeah, I also realized after the fact that it wouldn't work.  B/c the
config is reloadable the cred(s) in the SecurityConfiguration
instance(s) might have changed.

There's also I think nastiness in figuring out to whom the Assertion was
issued and driving cred resolution from that.  It would have to be based
either on the HoK SubjectConfirmation NameID, or the Audience.  The
latter is in general fuzzy because it has multiple values (including the
IdP itself).  Also IIRC it can contain values which aren't an individual
SP identifier necessarily.  So I think that idea is DOA.

With the reloading, there is actually an issue of TTL here.  The
deployer won't be able to remove/unload a signing credential if there
are still outstanding valid delegated Assertion tokens.  So I think the
instructions are going to have to detail that if one is doing
delegation, you have to treat signing creds like encryption creds in
metadata:  add the new one(s), leaving the old ones in place; wait
awhile; then remove the old ones.


> 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.

I do remember it now.  We didn't have a use case.  I think this may be
it. :-)  At least for credentials.

>
> 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.


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. 

The exact use case here is that these need to be resolveable from a
CredentialResolver injected into a SignatureTrustEngine, which is
injected into an Assertion validator. Given the existence of some
service that contains the creds, I'm thinking we could have a
CredentialResolver impl which uses the reloadable service as the basis
for what it resolves.  If the service say simply exposes a
List<Credential>, then the cred resolver would be trivially easy to
write, probably a handful of lines of code.

That cred resolver could be injected wherever.  Right now it's actually
probably easiest to just wire it (indirectly) into the Assertion
validator, since the validator currently assumes it's just being handed
the SignatureTrustEngine at construction time.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150820/46aac5d2/attachment.html>