Place for beans related to metadata providers?

Cantor, Scott cantor.2 at osu.edu
Wed Dec 10 22:52:55 EST 2014


Back from the airport and actually able to look at the config again, some 
corrections...
>
>I have to keep in mind the legacy schema also. The relying-party 
>compatibility support essentially has the same problem the metadata does. 
>I used a fixed bean for that, but if we want to, I guess we could follow 
>the same FactoryBean model you did and do it that way, which again maybe 
>suggests we do that in one place and share it.

Of course that's not true, the FactoryBean actually does the Resolver step 
and combines the Configs into the final Parameter result. Whereas in the 
runtime cases, that's happening (duh) at runtime in order to pull in the 
per-RP Config if it exists. So not possible to do it statically with a 
FactoryBean.

The part here that's potentially shared is the SecurityConfiguration 
itself or perhaps just the whitelist/blacklist portion.

As far as the FactoryBean, not sure. For now I'd say leave it, and let me 
look at the combination of things we need to support. We may want to 
create something dedicated to these "exposed" security settings in the 
root context (conf/security.xml ?) and just reference the beans in both 
the metadata and relying-party services.

I don't necessarily think they'll be changed much or that being reloadable 
would be a big deal. But let me see what the whole set of beans might look 
like and I'll suggest something. It was next on my agenda anyway.

>So firstly, the question is whether we think it will be common/important
>to have different configuration for runtime signatures and metadata 
>signatures.

It seems fair though to assume the dominant case would be for the 
white/blacklists to be for both, though, right?

-- Scott



More information about the dev mailing list