<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 4/22/14 11:20 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF7BFE97.4D3F0%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 4/22/14, 9:16 AM, "Rod Widdowson" <a class="moz-txt-link-rfc2396E" href="mailto:rdw@steadingsoftware.com"><rdw@steadingsoftware.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">These are both in some way to do summoning up the
net.shibboleth.idp.profile.config.SecurityConfiguration which needs to be
injected into each profile configuration.
</pre>
</blockquote>
<pre wrap="">
And all the ancillary parameters.
</pre>
</blockquote>
<br>
I'm not really sure that's true. I don't understand what the IdP
will be doing exactly here, but it's not clear to me that the
signing credential ref stuff would necessarily involve the new IdP
SecurityConfiguration. Depends on what we're trying to achieve.
See below.<br>
<br>
<br>
<blockquote cite="mid:CF7BFE97.4D3F0%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Dealing with the third (securityPolicyRef on the ProfileConfiguration)
first: We can either warn if we encounter this or we can plant a
reference
to an (externally defined) instance of
net.shibboleth.idp.profile.config.SecurityConfiguration.
</pre>
</blockquote>
<pre wrap="">
I don't think it fits well with SecurityConfiguration, actually, it's
really the thing we're not doing with an inboundFlowId.
</pre>
</blockquote>
<br>
<br>
Right, the securityPolicyRef has nothing to do with anything called
now or in the past SecurityConfiguration. In the new model it
corresponsds to that "chain" of security-oriented MessageHandlers...
which I think we recently decided would now become a subflow with
each handler wrapped in a WebFlow action adaptor. <br>
<br>
<blockquote cite="mid:CF7BFE97.4D3F0%25cantor.2@osu.edu" type="cite">
<pre wrap="">
If you look at the schema, this is one of those bad design spots where
he's defaulting in the value to point to something that's actually in the
file. What we can do is deperecate it, and take out the default so that
it's optional and if set, we warn and ignore. I think that's the best
choice.
</pre>
</blockquote>
<br>
Yes, I agree. I don't see how we could really support that in any
useful way by trying to translate it to the new code. It's just too
different.<br>
<br>
<br>
<blockquote cite="mid:CF7BFE97.4D3F0%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">So my question is what should I do about the signing credential
references?
I have been presuming that I need to summon up a
net.shibboleth.idp.profile.config.SecurityConfiguration and inject a
SignatureSigningConfiguration into it but:
1) (for Scott) how to I ensure that it collects all the other "sensible
defaults"
</pre>
</blockquote>
<pre wrap="">
I think what we need to do is create a file and bean that defines the
default SecurityConfiguration and all the various parameters. By default
every RP definition would summon up that prototype bean. If (in the common
case today) the signing credential is set, I suggest we use that to
override the Credential in the parameters, and warn that it's deprecated.
</pre>
</blockquote>
<br>
<br>
To step back: This is where I'm not clear what we are doing here
vis-a-vis the legacy config. If the intention is that 1) that ref
will point to an actual Credential and 2) we are trying to implement
roughly backwardly compatible behavior with the legacy config files,
then I'd say we probably don't need to that. You have a
credential, all you need is the other inputs to signing, which would
come from a SignatureSigningConfiguration. IF we asssume that none
of this really goes through or uses the new security parameters
resolution process, then the easiest thing to do is just grab the
global (i.e. OpenSAML) default instance of
SignatureSigningConfiguration from the ConfigurationService. That's
essentially equivalent to v2's use of the global OpenSAML
SecurityConfiguration (not to be confused with the new same-named
interface in the IdP). Then produce a SignatureSigningParameters
from that (somehow, maybe with specialized code, maybe with the new
appropriate -Resolver).<br>
<br>
As an alternative (actually this might be better), we could use the
Credential from the legacy ref to construct a
SignatureSigningConfiguration instance with *only* the credential,
and then it gets passed as the first one in the list/varargs that's
handed to the resolver - the others coming from wherever we
currently getting them, but starting at least with the one from the
relying party's (IdP) SecurityConfiguration. Presumably, based on
the relying party ID, etc, we can get at the new
SecurityConfiguration interface that is appropriate to obtain
those? If so, then I think it would work. <br>
<br>
<br>
But I'm still not sure of the machinery here.... I remember on a
call once we talked about something *completely* different: the
Credential ref being injected would be a proxy that that just
proxied the "first" signing credential in the relying party's
SecurityConfiguration's SignatureSigningConfiguration. But I'm not
sure how or whether such a notion fits in, or even makes sense.<br>
<br>
Maybe easiest to do this in person...<br>
<br>
<br>
<blockquote cite="mid:CF7BFE97.4D3F0%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">2) (for Brent) how do I summon up a SignatureSigningConfiguration given a
Credential. BasicSignatureSigningConfiguration might do what I need,
but again the
question how to get sensible defaults?
</pre>
</blockquote>
<pre wrap="">
I think we'll have to lay them out with Spring by hand, unless I'm missing
something. Or we just use OpenSAML's global default, but we kind of talked
about not doing that.
</pre>
</blockquote>
<br>
<br>
Well, there is the global OpenSAML one available from the
ConfigurationService, yes. That's easy. As I said above, if the
intention for the legacy schema is to mimic what v2 did, then using
the OpenSAML one wouldn't seem crazy. <br>
<br>
Or: I have more or less assumed that there would be an IdP
SecurityConfiguration (or a set of the 4 -Configurations) used as
the IdP defaults for input to the new security -Resolvers. (Although
Scott has pointed out that doesn't quite mesh with the way
defaulting worked in v2). Or it could be that this is a lonely bean
that lives in Spring somewhere and exists solely to serve this use
case. <br>
<br>
Or: Despite this being part of the legacy schema, if there is some
way that that code can get access to the new (IdP)
SecurityConfiguration that corresponds to that relying party, then
that's the more obvious choice, and closer to the native v3 design.<br>
<br>
Actually, of course, if the legacy v2 schema-using use case uses the
new security parameter resolver mechanism at runtime, then you'd
actually use all 3 of these (or 4 if you synthetically generate a
config from the credential ref that has nothing but the credential
and put it at the head of the list so that credential takes
precedence).<br>
<br>
(But I'm still feeling very confused. I'll stop typing now lest I
confuse myself even more).<br>
<br>
<br>
</body>
</html>