...
The V2 configuration files are copied to a new directory, conf.v2
The packed V2 warfile is copied to a new directory, war.v2
The directories logs and metadata are left untouched (note that leaving the latter in place means that new example metadata for the IdP is not generated).
Specific legacy files that are generally compatible with V3 (attribute-resolver.xml, attribute-filter.xml, relying-party.xml) are pre-populated into the new config directory; these make up the bulk of your older configuration, save for authentication.
The old relying-party.xml file is also copied to metadata-providers.xml
- The rest of the configuration is populated as for a new installation.
Finally, services.properties is altered to enable a legacy relying party configuration.
Next Steps
Authentication
After the upgrade you will need to configure authentication handling and make any adjustments required for advanced use (see Configuration), but authentication and UI considerations are typically the main thing you'll need to deal with to get things going and get back to a working system.
...
While there are strong parallels provided to what came with V2 (JAAS-based form login and RemoteUser-based authentication), there are key differences that have be accounted for in many cases:
- The vt-ldap JAAS module provided with V2 has been replaced with a newer implementation based on the successor project called ldaptive. While the newer module is generally more capable (and has the advantage that it's fully supported), there can be differences in configuration.
- The login form customization features in V2 were based on JSP, while Velocity templates are the strongly recommended approach in V3. Even if JSP is used, there will be inevitable changes required. In most cases, it's best to leave the default form in place during initial testing and save the UI migration for a later step.
Initial Testing
After starting the new version for the first time, watch for any errors in the log, and make a note of any warnings; most of those will be due to the use of a legacy relying-party configuration, but some will also note use of deprecated features or syntax. You can generally ignore deprecation issues until after you have a stable system.
If you encounter errors, you may be using features that are no longer supported and are encouraged to ask for help on the support list, but this should be rare.
You can test that the IdP is at least running successfully in the container with the status command line utility (idp.home/bin/status.sh or idp.home\bin\status.bat).
...