Finalizing TrustEngine config

[Brent Putman]

On 6/18/14 4:06 PM, Cantor, Scott wrote:
> I realized I still have a pair of basic trust engines hardwired in one of
> the Spring files, and I'm loading those into the message handlers that are
> doing the authentication work.

You're talking about these in idp-conf, right?:
system/conf/global-system.xml and system/flows/saml/security-beans.xml


>
> Brent, I see the SignatureValidationParameters class still has a slot for
> a trust engine, but I don't think the handlers would see it, they're using
> the one that's set on the handler. 


Yeah, I hadn't removed it yet, even though IIRC we had tentatively
decided to probably not use it at least for the signature-evaluating
message handlers.

I had thought that it might be nice to provide in the handlers support
for that, and if it's not set, use the one set directly on the handlers
as currently.  But I didn't think it was a priority, since it's unlikely
it would get used by anyone.


> Plus of course there's no such
> parameter set for the TLS client case.

Right, there's no cert trust engine defined anywhere on the current
security params, nor resolver, etc. 

> I'd kind of prefer to set the engine using the SecurityConfiguration
> somehow, because the natural place to define the engine(s) is inside the
> relying-party context where the rest of the security config is done.

Yes, seems natural.  Am I inferring then that you think the preferred
way would be to switch gears and use the SignatureTrustEngine on the
SignatureValidationParameters?  I'm sure that's doable in the signature
handlers, but in looking at them it's not as trivial as I'd hoped,
because of the way the generic TrustEngine-oriented superclasses are
written.

Btw, what's the difference between the SecurityConfigurations defined in
system/conf/security-config.xml and
system/conf/relying-party-system.xml?  Just noticed that they have the
same bean id (shibboleth.DefaultSecurityConfiguration).


> Should that be our goal here, or should I just find a way to define them
> elsewhere?


I could go either way I guess.  Standardizing on the
SignatureValidationParameters and having it live with the other security
config does make a certain kind of sense.  Of course, in reality, as we
had already discussed, it's probably unlikely anyone would ever use
anything other than the global ones based on metadata.


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