Place for beans related to metadata providers?

[Brent Putman]

On 12/10/14 4:58 PM, Cantor, Scott wrote:
> On 12/10/14, 9:51 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>> Other than conf/global.xml, is there currently any other logical place
>> for beans that would be injected into metadata providers?  Looking for a
>> place to wire in the placeholder default criteria for signature
>> validation, mostly to give users an easy-to-edit way to
>> whitelist/blacklist algorithms.
> Not currently. We can leave it in global or create a supplemental file and 
> load that in the default resource sets.

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.

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.

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


>
> A question I guess is whether we think we need separate rules out of the 
> box for metadata and runtime. If not, we probably want it in global and 
> not in relying-party-system for example.
>

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20141210/f5584a39/attachment.html