Place for beans related to metadata providers?

[Brent Putman]

On 12/10/14 10:52 PM, Cantor, Scott wrote:
> Of course that's not true, the FactoryBean actually does the Resolver step 
> and combines the Configs into the final Parameter result. 

Yes.  I initially thought about just injecting the -Parameter directly
to the factory bean(cause it's easier).  That seemed weird and
inconsistent (-Configuration is for what you configure....), but I was
also concerned about being about to share the same config with the rest
of the IdP.  Don't repeat yourself, per my last message.  So using
-Configuration actually resolving from it seemed to be more correct, and
flexible.

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

At least as far as the signature validation stuff goes - yes, it's just
the whitelist/blacklist.  In fact, I started to just have the factory
bean take WhitelistBlacklistConfigurations instead of the full
SignaureValidation-, but without a lot more work that doesn't work: we
don't have a plain concrete WhitelistBlacklistParametersResolver (it's
buried in an abstract resolver class) and the relevant criterion input
to the SignaureValidator also takes SignatureValidation-.  So all the
work didn't seem worth it, esp at this late stage, don't want to break
stuff.


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

That sounds like a good idea, esp if we introduce the new 4th IdP-global
set of config instances.  That would be the logical place for those.

I didn't look yet to see how the per-profile configs are actually
wired.  If we moved the config(s) up to user conf/security.xml, I
suppose one way to handle the multiple injections and still allow user
editing and possibility of divergence, would be to use bean aliases
(@name) to give a single shared bean many names, and then have the
profile configs injected with their specific named one.  If you want to
customize a single per-profile config, remove that bean alias and
declare a new bean with the name.  So the dependency would just be on
the well-known bean names, for each profile.

Might still be useful to distinguish between the IdP-global config and
the default per-profile config(s), for clarity if for no other reason.


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

Yes.