4.3.1 to 5.0.0 migration questions

[Cantor, Scott]

> I am having a look at what this migration process involves, it should be
> easier now our current IdP is running as containers (based on "jetty:10
>-jdk11-amazoncorretto").

I would argue quite the opposite, but I'm not going to keep beating that drum.

Jetty 11 is definitely more or less identically configured, but there are differences in logging libraries if nothing else that have to be addressed if the out of the box logging isn't used. Otherwise it's pretty much what they claim, a lateral change.

> What exacty are "idpnew-500" files ? The new default version, an updated
> and compatible version based on the previous ones I should rename to use
> in lieu of my current files ?

The former, absolutely NOT the latter. The idpnew files are not a new feature of the upgrade, but were limited in the past to plugins and various optional modules' files.

With 5.0, all files are now "managed" by one module or another so every file (or close to it) will end up with the new default version installed for reference (or for removal, that's obviously trivial with the Unix find command, which I run more or less right after I upgrade). That will happen on every upgrade, and even happens if you install over top with the same version, so that's one easy way to get a copy of any "new" default file.

The other difference is noted in the release notes, the idpnew files will always contain a collapsed version string on them now to allow them to stack up if desired and just for clarity.

> Are the regular config files (with their usual prefix) supposed to be usable 
> when a "dpnew-500" companion also exists ?

Yes. The idpnew files are never "live", barring somebody manually doing something extremely odd and ill-advised. They don't loaded or used, even e.g. In the case of automatic search for properties as they don't end in ".properties"

> We are redirecting authentication to CAS, and it seems"idp.authn.External"
> is no more. 

That’s not the case. That's a module ID, not a feature. Various modules that only managed files that were largely replaced in 4.1 with property-based approaches to configure features were removed. The old files remain usable but they're not files the IdP will pay attention to during upgrades.

In that case, the external-authn-config.xml file is, essentially, almost never needed, and so it was removed from the default install and is honored only for compatibility.

There is nothing about External that's changed, at least allowing that lots of things changed (optionally) in 4.1 to simplify the configuration by switching from XML files to properties.

The problem Shibboleth faces is that the majority of its base has been using it since long before many improvements were made to the configuration, and so most of the benefit is useless if not actively confusing to those deployers, while there aren't enough net-new deploys to take advantage.

We missed our shot, basically, assuming one thinks some of the newer approaches are in fact better.

Most of V5 is a directly compatible upgrade except that so many classes moved around that there are some number of deprecations to fix afterwards and in a small set of unusual cases, actual breaking classname changes made. The most prominent breaking change is the wiring up of basic-auth for HTTP client stuff. That's far and away the biggest thing that breaks outright because the older approach was just emergent after release, and pretty awful.

-- Scott