Place for beans related to metadata providers?

[Cantor, Scott]

On 12/11/14, 3:45 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

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

I don't think we have any impl classes exposed now. But I can also use 
parent beans and hide the class names too, so moving them isn't strictly 
required. In general, expecting users to enter class names is IMHO bad, so 
I've tried to avoid it regardless of APIs. But when it comes to more 
advanced cases, I don't want anybody to have to enter an impl class name 
if they're forced to enter a class at some point, since that essentially 
makes it an API.

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

There is one other one, a default configuration for the whole RP 
subsystem. That's not per-profile. The per-profile thing *is* the per-RP 
thing because profile configs are specific to RP definitions. It doesn't 
show up in the resolver functions you fixed because it's hidden inside the 
RP resolver and is used when no other configuration is set, which is the 
normal case.

But you're talking about something global to the IdP as a whole outside 
the RP subsystem.

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

I guess I'm inclined to make it "global" through explicit bean sharing 
rather than create some other configuration layer we'd have to expose 
somehow. In effect that's all it would end up being anyway if we injected 
it into those ConfigurationLookup functions. Just a bean that happens to 
be injected in multiple places.

-- Scott