For the time being, the work on a non-XML configuration is deferred due to feedback that XML is less of a problem than the file length and complexity. Since a non-XML version would likely be a separate delivered tool, and decoupled from SP releases, the work for 2.4 has focused on stripping down and defaulting much of the old configuration, and creating a new mechanism for handler setup. This will be documented before/during release and is fully backward compatible to any 2.x config.
...
| Table of Contents |
|---|
Goals
- Identify the options that are most commonly changed and hardwire the rest.
- Provide defaults without explicitly showing them to limit size of file(s).
- Identify the configuration scenarios that address 80% or more of use cases.
- Avoid the need to use XML for the most common scenarios.
- Provide constrained options that encourage recommended approaches to deployment.
- Allow straightforward migration from "simple" to "standard" configuration.
...
Sketching out how this could work, a list of hostnames in a [SHIB2:vhost] section could point to dedicated sections for each vhost. Those sections could include settings such as:
...
In other words, a section called [SHIB2:protected] could have key/value pairs like requireSession=1 and exportAssertion=1 (same as current options), establishing the settings that are in effect. Within the virtual host section, any "unknown" key values could be treated as path expressions whose value would be "protected", mapping them to the necessary section. The hardest part would be dealing with overlapping paths, since the XML format doesn't detect that, but it should be possible with some work. Regular expressions could be signaled with a '~' character, and would generate a PathRegex rule in the XML.
...