Mulling on this, it means that the IdP will need

• an http client bean name to use

• An http client security parameters to use

• Idp.home (or the location of the file in dist

Also, because it would be good to share it that needs to go into a spring file that can be added to the command line’s ‘additiona spring files’. I’ll research this last (there must be one) but I’m not sure what the protocol is for adding the properties (for the first two) do I just slam them into idp.properties at an appropriate place and document them?

moving any hardcoded locations that “matter” into a property file that we load from the local dist/ tree.

That's nice. It aligns it very nicely with plugins (although I’m tempted to put the plugin -I plugin -L URLs into the same file. We already have a file called in there with the versions (current, previous) but I’m not sure I want to use that.
I think I’ll generate it programmatically in the installer rather than have it copied (which is just needless work)

do these checks at IdP startup and have that logged?

Why not? It comes with the same caveats as the plugin metrics but I can live with that

I have a half formed idea to pull a lot of this function into the IdP (to support metrics) and probably as far back as shib-shared-profile (so that the sop can just collect it). When I get my head out of the weeds I’ll start that,

I guess this brings to mind…are we, or could we, do these checks at IdP startup and have that logged? Maybe default on, have a property to turn it off.

My inclination is I guess that we maybe consider moving any hardcoded locations that “matter” into a property file that we load from the local dist/ tree. That just means if the worst happens, there’s a place people could fix the URLs.

Aside from that, I guess the proposal is fine (I’d probably say idp-versions.properties and avoid multiple dots). It shouldn’t be hard to replicate something else into S3 though the upside here is a lot less.

Current state

Plugins carry their update locations (https://shibboleth.net/downloads/identity-provider/plugins/plugins.properties and http://plugins.shibboleth.net/plugins.properties)

These defaults are also baked into the plugin installer for the -I (install from id) and -L (list all) parameters

For this case

1. Are we happy to introduce a new “API” a downloadable file called “idp.versions.properties” ?

2. If so, where do we put it (“https://shibboleth.net/downloads/identity-provider/”) ?

3. And so we want it backed in AWS ?

4. Are we happy with the the current names for the plugins?

5. I will make up some API inside the installer for the defaults for both the IdP and plugins locations. (probably in idp-admin-api or impl?)

… and more

And hey presto there is the file!
(with delete on failure)

I have been borrowing plugin.properties (because it has all you need). It comes at the cost of polluting the properties name space.

So 100% agreed: yes, lets have a different location.

And again looking forward I would suggest that we start considering

• having idp.plugin.properties(as a symbolic link for plugin.properties, then over time we can move)

• have (say) idp.version.properties

• have (say) sp.plugin.properties and sp.version.properties

They can all live in the same git repo and use the same publication mechanism (can they?). I was going to suggest putting the keys there as well but no, we have a mechanism and a well known location for that.

This is getting slightly complicated so if the ideas haven’t settled down by Friday we can discuss then.

Meanwhile (using a borrowed & local plugin.properties and pretending to be V4.3.0

I meant the directory layout for the software (or were you planning to go to Nexus for the information?). Either way, none of that has been terribly stable over time. I was surmising we may need the equivalent of plugin.properties for the IdP itself.

Of course. You are talking about http://shibboleth.net/downloads/PGP_KEYS

yes. Lets make that something that is

• Overridable on the command line and

• Architectured as being better than a static final private string KEY_LOCATION

suggestions ? I could almost support having it only available as a parameter

Well yes and no. The “hardwired path” ship sort of failed when we added -L (list available) and -I (install from Id) qualifiers to the plugin command, sure they can be changed with each IdP release, but so that the update command.

Actually, it sailed as soon as we shipped our first plugin with that URL inside it - we cannot move from there quickly without a good plan (which gives us a chance to move the IdP foward).

I’m disinclined to make the IdP pretend to be a plugin because then we need to stop it being installable via the plugin command - and I am guessing you didn’t either, but we could always have the URLs available elsewhere (even just as a static List<URL> somewhere which would be a reasonable compromise.

Also, the command line (obviously) has a --updateUrl qualifier - like the plugin command has.

Finally, I’m not 100% wedded to the idea of doing this, but I thought I'd kick the wheels and see where we ended up.