SignAssertions action not needed ?

[Brent Putman]

On 2/4/14 1:31 PM, Cantor, Scott wrote:
> On 2/4/14, 1:21 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>> Also need to settle on and work out how the whitelist/blacklist
>> algorithm URI's from DecryptionParameters and
>> SignatureValidationParameters actually get applied, but I think that's
>> probably just updating the Decrypter and SignatureValidator code to
>> support those inputs, in some fashion.  Since I just reminded myself of
>> it, I'll work on that this week.
>>
> Yes, I'm presuming we want blacklisting to be an input to the construction
> of the parameters, not imposed after.

Yes, for the "generation" cases of signing and encryption all the inputs
(including white/blacklisting) ultimately produce the actual effective
values to use, which are reflected and held by the corresponding
-Parameters instances (which don't carry white/blacklists).  It's
basically for example:  SignatureSigningConfiguration(s) + (other inputs
TBD) --feed-to-> SignatureSigningParametersResolver --generates->
SignatureSigningParameters.

For the "consumption" cases of signature validation and decryption, the
-Parameters do carry the white/blacklists since that's computed for what
should be in effect for a particular invocation at runtime (e.g. based
on relying party, etc).


>  On the validation side, it does
> probably have to be part of the validation process, possibly as just a
> supplementary validator added to others, or maybe it's just a policy
> rule/message handler.

I had up to now actually been (fuzzily) conceiving of white/blacklisting
as being built into the actual SignatureValidator (and Decrypter) as a
fundamental part of what they do.  (Or for signature, maybe the
SignatureTrustEngine).  Although in looking at it just now, supplying
params via the SignatureValidator and TrustEngine interfaces may not be
the way to go...maybe an external validator does make more sense for that.

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.

But: so in v2,  the Decrypter (which of course we never have actually
used in the IdP) was actually more or less intended to be used
(generally) like a singleton, in that you could configure just one
instance with the appropriate resolvers and use that for your decryption
needs across many invocations of decryption.  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.

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

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

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