ModuleConfiguration

Overview

V4.1 introduces a new configuration management aid to the IdP called "modules", or "IdP modules" to distinguish them from other uses of the term. The point of an IdP module is to encapsulate information about an optional feature of the software, together with a way to install, update, and remove optional files that are needed to use the feature.

As an example, if you're using Duo, the feature requires at least a view, a set of properties, and occasionally an XML file in a particular spot for more advanced configuration. If you're not using it, none of those files are needed. So, if you're not using Duo, having those files installed and in the way is just annoying and confusing. Making the Duo login flow a module allows the system to recognize whether the feature is being used, deploy initial versions of the needed files after installation of the IdP, and remove them if the feature is no longer needed.

Extending this approach to as many optional features of the system as possible, we can reduce the initial number of files installed as much as possible, and make the system more able to report about what features are being used.

The module system works in concert with the new Plugin model to complete the lifecycle by allowing new features to be delivered and updated via remote, signed packages, and the plugins expose their features as modules to allow configurations to be installed and updated.

To manage expectations, this is still a Spring-based application that is wired together very statically and relies on a lot of older technology that is not amenable to dynamic plug-and-play behavior. The goal was not to redesign the system, but to redesign as much of the configuration as possible to work in a more "default to safe" way to reduce the number of files that a new deployer would be faced with. Many features are used by few (or no) deployers, so having to accommodate those configurations by default became less and less attractive.

It is possible that future major versions may remove certain features and turn them into optional plugins that would be installable separately to shrink the footprint further.

Using Modules

The only real need to interact with the module system is to enable (or occasionally disable) modules in order to populate configuration files to get started using a feature that has been modularized. This will be noted in the documentation where necessary.

The full set of options can be viewed with the "--help" option. Principally there are options to list modules (the default), get detailed information on a module, and to enable or disable one or more modules.

Detailed module information will also include the exact files the module "owns" and will attempt to manage for you. The module system is designed to be "safe" in the sense that it will not generally overwrite files you have created or changed unless special circumstances warrant it (and usually that will be noted with a message after enabling the module). This is familiar to people used to RPM, and you will find files with ".idpnew" and ".idpsave" extensions as a result of the module system preserving older files or creating new default files without replacing your own copies. For the exact rules it follows, see the Modules development topic.

Also note that after upgrading from an older version, you will find that most/all modules will claim to be "enabled". This because in most cases, that status depends on the existence of the configuration files that the module is managing, and most of those files existed prior to the module system's development. The point of this is that you can now explicitly note what those are, and if you aren't using specific features, you can simply disable many modules and get rid of several files you don't need by doing so.

Of course, it is strongly suggested that actually enabling or disabling modules be limited to non-production systems with the resulting filesets managed through standard configuration management approaches.