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.
...
Listener
Unix and TCP options should could be expressable in simple form, but a Unix build could rely on the Unix option by default and Windows would default to TCP with the default settings, so a typical setup could say nothing about it.
...
It should be "hard" to support multiple certificates, so the simple format should not support it, but will need explicit support for key rollover, which probably means including key "usage" constraints.
SecurityPolicies
Most of this material should be hardwired with a few defaulted settings exposed.
Probably will want to include new algorithm blacklist/whitelist feature (shouldn't have to compromise long term security for simpler format)Already factored out into separate XML file for next release.
Implementation Notes
Windows INI format is probably the logical choice for the core config, though it makes repetition of property sets and inheritance very ugly. Probably need to forget any sort of inheritance at all.
...
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.
...
| Code Block | ||
|---|---|---|
| ||
[ApplicationDefaults] entityID=https://sp.example.org/shibboleth REMOTE_USER="eppn persistent-id targeted-id" [Errors] supportContact=root@localhost [Credentials] key=sp-key.pem certificate=sp-cert.pem [SSO] SAML2=1 Shib1=1 DS=https://ds.example.org/DS/WAYF [Logout] SAML2=1 Local=1 [CustomHandlers] Metadata=1 Status=1 Session=1 ; identifies named sections for each metadata source [Metadata] InCommon SWITCH [InCommon] url=http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml backingFilePath=InCommon-metadata.xml minRefreshDelay=600 reloadIntervalmaxRefreshDelay=28800 maxValidityInterval=604800 certificate=incommon.pem [SWITCH] url=http://metadata.aai.switch.ch/metadata.switchaai.xml backingFilePath=metadata.switchaai.xml minRefreshDelay=600 reloadIntervalmaxRefreshDelay=3600 maxValidityInterval=604800 authority=SWITCHaaiRootCA.crt.pem verifyDepth=5 |
...