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