Place for beans related to metadata providers?
Brent Putman
putmanb at georgetown.edu
Thu Dec 11 10:45:11 EST 2014
On 12/10/14 6:14 PM, Cantor, Scott wrote:
> As I mentioned on the call, the only outstanding config matter I had left
> was studying the security configuration pieces and how to expose them to
> users, if in fact I want to.
Ah yes, I remember now.
>
>
> One aspect is whether any of the classes are in -impl, but I don't think
> these are.
Actually, I think all the security Basic*Configuration classes are in
security-impl. There's not much to those, they're really just beans
with getters/setters, so I wouldn't have a problem moving those to -api
if that's what you are suggesting.
>
> So firstly, the question is whether we think it will be common/important
> to have different configuration for runtime signatures and metadata
> signatures.
Well, for this particular case of the SignatureValidation- stuff, it's
pretty much only the whitelist/blacklist at issue (only other thing is
the trust engine slot, which the filter doesn't use). I would think it
would be desirable to be able to have a common config for that - e.g. if
you want to blacklist something and want it "global", it would be nice
to be able to do it in 1 place, not 2 or more. Of course, you might
want them to diverge and that's perfectly possible to configure also.
Related: for that sort of "global" config reason: We don't really have
that in general in the IdP right now. We have the OpenSAML library
defaults, but those aren't editable without changing code. The next
"layer" down in the IdP is the per-profile configs (followed by per-RP
configs). If we're going to enhance all this and if it is easily
achievable, I think it might be nice to have a 4th "layer" of security
configuration that is truly the IdP-global config. It would be inserted
in the effective config chain between the OpenSAML library one and the
existing per-profile ones. Once we have a beans file place for it, I
believe all that's necessary to change is those config lookup functions
and so they'd just need a way to pull or lookup or be injected with
those global instances.
If we did that, then I think that this IdP-global
SignatureValidationConfiguration would be the most natural candidate to
share in common between the runtime stuff and the factory bean for the
SignatureValidationFilter (the latter is by definition almost a "global"
thing).
More information about the dev
mailing list