Security parsing - signing and defaults

[Brent Putman]

On 4/22/14 11:20 AM, Cantor, Scott wrote:
> On 4/22/14, 9:16 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>> 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.
> And all the ancillary parameters.

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.


>> 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.
> I don't think it fits well with SecurityConfiguration, actually, it's
> really the thing we're not doing with an inboundFlowId.


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.  

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

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.


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


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

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.


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.

Maybe easiest to do this in person...


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


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. 

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. 

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.

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

(But I'm still feeling very confused.  I'll stop typing now lest I
confuse myself even more).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140423/fb08ec0b/attachment.html