Place for beans related to metadata providers?

[Cantor, Scott]

On 12/10/14, 10:27 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

>What I really wanted to do was put it in metadata-providers.xml, to get 
>the locality of reference.  I thought we somewhere for something had 
>introduced (or at least discussed) the ability to mix custom schema and 
>beans schema.  But not here apparently.

No, we more or less moved away from that model for the most part. There 
are some weird parsing behaviors involved with that.

>Maybe we should make a new beans file like 
>conf/metadata-provider-beans.xml, or something?  At least it will be 
>alphabetically sitting next to the thing that uses it, so users will at 
>least see it more readily.

We can, I'm just suggesting we could consolidate it if it's the same bean 
we want to use for relying-party policy.

>(Btw, I still don't know my way around our bazillion config files.  
>Perhaps we have created a monster... ).

Most of them are rarely going to be touched, but the strong feedback I 
keep getting is that if it's not a GUI it's considered unusable by many 
people anyway so after that we're haggling over details.

None of this is really documented yet anyway, so it's hard to judge until 
that's no longer the case.

>Well, this thing is currently really only for the 
>SignatureValidationFilter.  I guess what you're saying is we could split 
>the effective SignatureValidationConfiguration out to its own bean so it 
>could be reused for both metadata and runtime cases.  That might
> be a good idea.  I thought about trying to re-use what we have, but we 
>don't currently have anything; the 
>shibboleth.DefaultSecurityConfiguration doesn't expose the child configs 
>with ID's, etc, so I didn't want to muck with it.  But we could I guess.

Yes, it's monolithic right at the moment, but it doesn't have to be.

>Speaking of relying-party-system.xml...   The 
>shibboleth.DefaultSecurityConfiguration instance is used for all the 
>per-profile defaults, right?  I would have assumed we'd want those 
>editable by the user.  But then we have the big DONOTTOUCH warning on the 
>whole
> system tree saying not to modify.  Is that kind of a conceptual 
>disconnect, or am I missing something (which is entirely possible)?

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.

Initially I left it hidden and exposed just a property to do the most 
common thing people want, switch SHA-2 on and off. But that's global, just 
like now, and I need to go back tomorrow or Friday and come up with a way 
to expose more of that.

We don't want every piece of it to be editable necessarily, but if moving 
it makes sense we can do that.

One aspect is whether any of the classes are in -impl, but I don't think 
these are.

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.

Initially the reason I hid it all for the legacy case was as another 
example of forcing people to migrate to native Spring relying-party.xml if 
they wanted to customize that bean.

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

-- Scott