Finalizing TrustEngine config

Cantor, Scott cantor.2 at osu.edu
Wed Jun 18 20:06:53 EDT 2014


On 6/18/14, 7:50 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

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

Yeah, I'd forgotten I never finished all that.

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

>From the strictly outside perspective using it all, yes, it seems to fit
together with the rest of the parameters and such.

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

I think I had created security-config.xml and then decided not to use it
and forgot to delete it. I don't think it's loaded, but I'll fix it.

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

No, but it's not inconceivable one might use different engines for a set
of RPs I suppose.

-- Scott




More information about the dev mailing list