Scriptable DataSealerKeyStrategy Question

[Cantor, Scott]

On 10/15/19, 5:41 PM, "dev on behalf of Snyder, Bill" <dev-bounces at shibboleth.net on behalf of bpsnyder at amazon.com> wrote:

> I’m trying to avoid making any custom changes to the idp-conf/src/main/resources/system/conf/global-system.xml file
> as part of my solution. 

It is impossible to do this without redefinition of all of the higher level beans up at least 1-2 levels from where this one is injected. It's a waste of time. I would pull in the changes from the master branch in this specific area and use the new property I defined for this purpose to do it, so the new bean can be defined by itself.

For the purposes of the intended audience (InCommon TAP container deployments), any future patches can be applied underneath a layered commit/change on top to keep it working until it's part of a release. I don't have any reason to think this specific change is going to be revisited unless it doesn't work properly, and that will be much more likely to be found out if it gets tried out now.

> Along those lines, I’m assuming the class for that bean should be set to
> “net.shibboleth.utilities.java.support.security.impl.ScriptedKeyStrategy“ and that we should be passing in parameters to
> that bean in its definition.  I have looked but have not found an example of doing this (I have seen the test harness).  Am
> I misunderstanding how this is ultimately supposed to be used?  If not, is there a complete example somewhere
> showing the bean definition, the corresponding script, as well as where to place that script?

I don't have an example, I will have to draft one tomorrow or so.

Scripts can go anywhere. I put mine in conf/ or in whatever folder the file referencing it is in, but it doesn't really matter to the code. I don't imagine a lot of people put things outside the main installation tree, but I'm sure some do.

-- Scott