<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 8/20/15 2:39 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:6F3247F6-5F81-44F6-A920-E45523BBBFF9@osu.edu"
type="cite">
<pre wrap="">On 8/19/15, 11:59 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:6F3247F6-5F81-44F6-A920-E45523BBBFF9@osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
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.</pre>
</blockquote>
<br>
I do remember it now. We didn't have a use case. I think this may
be it. :-) At least for credentials.<br>
<br>
<blockquote cite="mid:6F3247F6-5F81-44F6-A920-E45523BBBFF9@osu.edu"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:6F3247F6-5F81-44F6-A920-E45523BBBFF9@osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>