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.
...
Need to "compact" this behavior into a set of necessary options for common use cases.
Have to maintain WAYF/DS capability.
Could include support for "known" but optional protocols (e.g. ADFS) using controlled try/catch around creation of plugin.
Hardwire the location to /Login, and perhaps use ordered set of protocol/handler names to build the chain.
AssertionConsumerService / Logout / Misc SAML endpoints
Hardwire themthe locations, perhaps with a simple on/off toggle for logout, artifact, NameIDMgmt.
Could include support for "known" but optional protocols (e.g. ADFS) using controlled try/catch around creation of plugin.
...
Will have to include a set of repeating options to designate metadata sources.
Don't need complete filtering support, but key filters should be exposed with simple properties.
This looks like the most complex "variable" part of the configuration, particularly to support indirect signature verification.
Probably want this to be identical to whatever "simple" format we come up with the IdP since it's common to both.
TrustEngine
Hardwire it, standard engines have no configurable settings anyway.
...
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 vhost "identifiers" hostnames in a [SHIB2:vhost] section could point to dedicated sections for each vhost. Those sections could include settings such as:
- canonical hostnameIIS site instance ID
- aliases to permit (on IIS at least)
- scheme(s) and port(s)
- entityID override (perhaps paired with optional "prefix" to allow path-based vhost subsets)
...
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 reloadIntervalminRefreshDelay=600 maxRefreshDelay=3600 maxValidityInterval=604800 ca-certificatesauthority=SWITCHaaiRootCA.crt.pem verifyDepth=5 |
| Code Block | ||
|---|---|---|
| ||
; same as Apache Example with additional sections
; enumerates hostnames to install for
[vhosts]
sp.example.org
altsp.example.org
[sp.example.org]
SiteID=1
/secure=protected
; protects everything under /secure
[altsp.example.org]
SiteID=634655888908
~/secure/=protected
; protects any path containing secure
; defines a "class" of settings to apply
[protected]
requireSession="1"
|
| Code Block | ||
|---|---|---|
| ||
; same as Apache Example with additional sections
; default entityID is https://sp.example.org/shibboleth
; enumerates hostnames to install for
[vhosts]
sp.example.org
admin.example.org
[sp.example.org]
/secure=protected
; override entityID for /admin path
entityID="/admin https://admin.example.org/shibboleth"
[admin.example.org]
/secure=protected
; override entityID for entire vhost
entityID=https://admin.example.org/shibboleth
[protected]
requireSession="1"
|