<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 12/10/14 4:58 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:7916A150-1CBA-49A0-97FC-5679F3E8B568@osu.edu"
type="cite">
<pre wrap="">
On 12/10/14, 9:51 PM, "Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:putmanb@georgetown.edu"><putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Not currently. We can leave it in global or create a supplemental file and
load that in the default resource sets.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
(Btw, I still don't know my way around our bazillion config files.
Perhaps we have created a monster... ).<br>
<br>
<br>
<blockquote cite="mid:7916A150-1CBA-49A0-97FC-5679F3E8B568@osu.edu"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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)?<br>
<br>
</body>
</html>