...
If you're coming into this cold, you really need to review these topics first, just to get the lay of the land, and because the core "language" for many of the configuration files is Spring, and because debugging your changes will usually require some logging familiarity.
If you don't know Spring XML configuration syntax, that's not unusual, but doing a little bit of reading on it will be essential, if not right away then almost immediately after you try and actually configure something.
To configure a new IdP from scratch, you will need to address these areas first:
Attribute Registry (optionally)
A Hello World module is available that will allow you test the system at this stage without diving into actual SSO protocol considerations.
The core requirements to proceed with SAML support are:
If you need to dig into more advanced SAML configuration needs, or need to interoperate with commercial cloud services, you will usually need to tackle these areas:
CAS support is discussed in:
OIDC support is discussed in:
Advanced configuration topics:
Finally, configuration related to "productionalizing" an IdP:
Installation Layout
The following summary will guide you in understanding the installed software layout and how to locate important files.
...
Directory | Explanation |
|---|---|
bin | Contains command line tools, and any Java libraries needed during installation. During upgrades files from the distribution will be overwritten, but additional files that you add will be preserved, so you can store your own command line scripts here. |
conf | The main configuration tree. During any installation (first time or upgrades), files are never replaced in this directory. New files required by the IdP version being installed will be populated if and only if they do not exist. |
credentials | Contains your keys, certificates, and keystores, as well as credentials on which you rely such as for metadata signature validation. Files in this directory should generally be readable only by the user account the IdP will run under (certificates aren't secret, but it's easiest to just lock down everything). During any installation (first time or upgrades), files are never replaced in this directory. In unusual cases, new files may be created if they do not exist. |
dist | Contains the original/default versions of the contents of the conf, flows, messages, and view directories. This folder is always deleted and re-created from the distribution on every install. This directory can be used as a reference against any locally modified copies of these filesFormerly just a copy of all the user-modifiable files from the distribution, this directory now also holds the state of installed plugins, and is used to recreate the war file properly when it is rebuilt. While you are free to look at anything in this folder, do NOT remove or alter it in any way. In the event of an accident, you can recreate this directory by repeating the installation process (i.e., as a same-version upgrade) and then reinstalling any plugins. |
edit-webapp | This directory is created on initial install and thereafter files may (rarely) be added during upgrades but not overwritten. You may place any local configuration you wish to include in your packed warfile. During warfile creation, the contents of this tree are copied over top of the webapp directory, from which the war file is then built. Thus, it is an overlay tool for your local modifications and extensions. |
flows | Contains any user-editable Spring Web Flow definitions. During any installation (first time or upgrades), files are never replaced in this directory. New files required by the IdP version being installed will be populated if and only if they do not exist. |
logs | Contains the IdP diagnostic and audit logs by default. |
messages | Contains internationalized message properties used in various UI templates. This contains only new or overriden message properties or post-install translations; all of the default messages and translations are in the system tree. During any installation (first time or upgrades), files are never replaced in this directory. New files required by the IdP version being installed will be populated if and only if they do not exist. |
metadata | A storage location for SAML metadata used by the IdP (see MetadataConfiguration). During initial installation, some representative SAML metadata for the IdP is generated based on the installation inputs and placed in this directory in a file named idp-metadata.xml. Note that the IdP does not need to load its own metadata. Also note that the metadata is generated as a one-time operation during installation. It does not result from an in-depth analysis of the IdP configuration and does not change when the configuration changes. It's a starter example, not a real metadata source. |
views | Contains Velocity page templates displayed to users of the IdP. While JSP views (and the older taglibs) are generally supported, most of the default webflow views provided are now Velocity templates that can be maintained outside the warfile and changed at runtime. During any installation (first time or upgrades), files are never replaced in this directory. New files required by the IdP version being installed will be populated if and only if they do not exist. |
war | Contains the packed IdP warfile for container deployment. The warfile can be rebuilt at any time by running the build.sh or build.bat script in the bin directory. It wll prompt you to verify the installation directory (which in theory allows for multiple installations). |
...
When upgrading, the installer uses the Module system to re-enable all active modules, resulting in new files being added to the system and old files usually left alone, with the distributed versions of those files added with an “.idpnew-<version>” extension for easy comparison. On rare occasions, files may require overwrite, in which case the original file will be preserved with an “.idpsave” extension.
...
Configuration Changes (and Non-Changes) from Earlier Versions
Please refer to the ReleaseNotes for the 5.x releases for the relevant changes to be aware of when upgrading, which are minimal in nature for most deployers.
...