SignAssertions action not needed ?

[Brent Putman]

On 2/5/14 9:58 PM, Cantor, Scott wrote:
>
> I assumed because they were interfaces exposed via ProfileConfiguration
> that the point was for the profile actions to consume those interfaces.

No, not at all.  The point of having on the ProfileConfiguration was to
hold the RP/profile-specific settings, if any.  These get combined with
(lets say, this is TBD) library defaults and configured IdP global
defaults (which themselves are *also* represented by other instances of
-Configurations), and other inputs (e.g. metadata-based algo stuff where
appropriate).  All goes into a mixing bowl (the -Resolver) which
produces a -Parameters instance that actually gets used at runtime.  I
realize that that is not really clear, because that combining/resolution
process and components is the stuff that we don't have yet. (Some of
that TBD stuff might be general enough to go into OpenSAML, but a lot of
the concrete impl is probably IdP-specific, in terms of the -Resolver
impls and using IdP-defaults and ProfileConfiguration and so on).

>  
>
> I don't really grasp the difference between the -Configuration interfaces
> and the -Parameters classes, which seem like they overlap.

Yes, the properties are similar and overlap because the idea is that the
-Parameters are mostly produced from, amongst other things, the
-Configuration (+ other inputs like metadata + logic).


>
> Whatever we do, what I'm going for is that the actions shouldn't have to
> call into any further code to derive the signing/encryption settings to
> use. 

Exactly, that's exactly what the -Parameters are for.  Those are the
things that the actions know about, nothing else.  The actions consume
the computed -Parameters which are resolved in the above TBD way.  There
will of course be one or more Actions which invoke the -Resolver(s) to
produce the -Parameters.  That's conceptually similar to what we do for
example with metadata - we have one Action/MessageHandler which resolves
the metadata *once* and then it gets consumed by other components.  Same
general idea.


> That should be what's exposed on the
> ProfileConfiguation.getSecurityConfiguration().get*() methods. So that's
> how I thought those interfaces were meant to work, that those were the
> *effective* options to use.

No, literally the other way around.  -Parameters represent the
derived/computed *effective* values that are used by runtime
components.  -Configuration represents the "static" config (and there
would likely be more than one "level" of a -Configuration) . 
-Configuration(s)  combined with resolution/computation/derivation logic
in a -Resolver produces a -Parameters instance.

Honestly, I thought the choice of the terms "parameters" and
"configuration" was intuitive, but I guess not.  :-)


> They seem
> to have the same fields, just one an interface and one a class.

And the reason for the class/interface difference is that: -Parameters
are effective values produced by a resolver.  It's just a simple bean
that holds values, so it really doesn't make sense to have an interface.

-Configuration on the other hand is going to appear in many places in
the actual system.  The nature of those is/was unknown in advance (to me
at least), so it made more sense to have an interface to avoid being
locked into assumptions about how those will actually be implemented. 
For example, the ProfileConfiguration one may in fact just be a simple
bean (in our Basic- impl style) that gets populated in some way, but the
OpenSAML library default one might be a different impl that just has
hardcoded defaults, or that reads from a classpath resource, etc.



>> 2) explicitly reconceive Decrypter as an instance-per-use class that is
>> constructed with DecryptionParameters.
>>
>> Still thinking on it, but slightly leaning at the moment to #2, since
>> it's more parallel with the way the Encrypter works as a instance-per-use
>> component (at least the SAML subclass does).
> I would generally prefer #2, and I guess I assumed it since that's how I
> coded the action for the time being.


Ok.  I would at least for the time being change the code to use
DecryptionParameters just to avoid confusion. 


> I don't think in practice you see much call for different validation
> behavior per relying party. I've never supported that in the SP and it's
> never really come up.

Yeah, that's mostly what I thought.  I was only considering it because
it was a logical consequence of the way the -Parameters had been
defined.  As I mentioned in the MessageContext notes, it was just an
idea to support a dynamic TrustEngine, which I think takes only a couple
lines of code.


>  It's the generation side (signing/encryption) where
> there's substantial need for variability.

Yes, of course.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140205/3ca85e60/attachment.html