SignAssertions action not needed ?

[Cantor, Scott]

On 2/5/14, 9:38 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Related: I saw what you did today with the Decrypter and new constructor
>taking DecryptionConfiguration.  That definitely wasn't what I had been
>thinking - but I'm not sure it's wrong, it depends.  I had not been
>planning that the security -Configuration classes
> would be inputs into anything other than the corresponding -Resolver
>which produces the associated -Parameters (i.e. like my above example for
>signing).  All other runtime components would consume only the
>-Parameters instances.

I assumed because they were interfaces exposed via ProfileConfiguration
that the point was for the profile actions to consume those interfaces. So
that led me to want to pass the interface instance back into the Decrypter
to populate it.

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

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

>In *that* model, using a DecryptionConfiguration for construction might
>sort of make sense to supply the various -Resolvers, but... Thinking
>about how to apply white/black lists (if done in the Decrypter itself,
>not external), that would most definitely *not* be done via
>DecryptionConfiguration, since that info can vary from decryption
>invocation to invocation.  So it therefore has to be based on
>DecryptionParameters.

I'm not understanding the difference between these two things. They seem
to have the same fields, just one an interface and one a class.

>So.. the two options I see are:
>1) we add DecryptionParameters args to all the decrypt* methods to supply
>the per-invocation info, or
>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.

>Also, just noting that this is actually conceptually sort of related to
>the same issue I mentioned in my MessageContext notes re: the use (or
>not) of the SignatureValidationParams SignatureTrustEngine: whether to
>support use of a runtime dynamically-derived
> trust engine per invocation (via SignatureValidationParams), or to use
>one that is statically wired into the signature validating
>MessageHandlers (currently they do the latter).

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. It's the generation side (signing/encryption) where
there's substantial need for variability.

-- Scott