Security parsing - signing and defaults

[Cantor, Scott]

On 4/23/14, 7:45 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

>To step back: This is where I'm not clear what we are doing here
>vis-a-vis the legacy config.

That specific question is not answered at this point, so I was merely
speculating. I've spent more time just working how the new model works and
getting it into the flows without thinking about how it's configured
underneath,

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

We could, yes. I hadn't considered that, I guess I was assuming we'd avoid
special-casing it to that degree and try and adapt it into something
closer to the new model.

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

That's close to what I had in mind in the note you replied to, same basic
intent.

And yes, I already have it implemented to pull the *Configuration objects
from the RelyingParty's SecurityConfiguration, that's all in place just
waiting for your resolvers to get done and tested. What Rod's doing is
figuring out where we get those *Configuration objects from to start with,
which I hadn't figured out yet, and how that fits with the old
signingCredential option.

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

Well, we discussed proxies as a solution to the object reloading concern,
yes, don't recall the rest specifically. But no, it doesn't sound useful
at this point. I don't think any of the code that will be *consuming* a
Credential needs any kind of legacy behavior like that, we're going the
other way, from the old config option to the new
SignatureSigningConfiguration structure so I can hand that to you.

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

Yeah. This is the part we just need to decide on, rely on the OpenSAML
defaults or just duplicate them in the IdP for self-contained maintenance
and a degree of independence, given that we'll want to be able to override
them anyway.

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

Yes. That is my inclination, whatever the form.

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

There's no reason it can't. The legacy schema is being parsed, but the
objects that come out of that are new, not old. And it's really not the
schema that's legacy now, just that signingCredentialRef. For now at
least, this is the syntax for V3 relying party config, modulo adding new
stuff to it.

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

Let me count the 4 you mean, just so I'm not lost:

Bare config with Credential alone
Relying Party config
IdP default config
OpenSAML default config

And I was basically suggesting we merge the first two somehow at runtime,
and I think that's correct because the thing producing the RelyingParty
config *is* the code parsing the legacy schema.

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

I'm not especially, so happy to talk it through on a call. Maybe I'm
missing something and that's why I'm not confused.

-- Scott