Page Comparison

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.

...

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.

StorageService / SessionCache / ReplayCache / ArtifactMap

...

Not needed for Apache, but no way to avoid something comparable for IIS.
Could maintain a separate XML file, but seems better to come up with a non-XML alternative because of the need to reference hostname(s).
A simpler format might also be "pluggable" into standard config.
The properties themselves are generally "flat" and simple to express without XML, so the change is in how to associate them with content without the nesting but without implementing htaccess in IIS.

...

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.

...

Mostly hardcoded already, probably can hardwire the resta few simple properties will do.

RelyingParty

Needs analysis, but inclined to omit support for it.
Most common use is probably to override credentials, and I don't think we want to support that.

...

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.

The various plugins require DOM fragments to supply properties during construction, so the implementation will need to construct these fragments. If it's really possible to turn "simple" into "standard", the most sensible thing to do is just generate the "standard" XML and load that using the existing code.This

leads into the problem of how to specify the configuration style in use, and support the competing goals of using the simple form by default in new releases, but supporting the standard form after an upgrade with no special additions. The configuration pluggability layer has features designed to allow alternative implementations, but those features would require setting environment variables or using special commands and options. So the fallback position would be to stick with the default plugin type of "XML" and just auto-detect the format from inside that pluginThat also suggests perhaps doing this with a stand-alone tool that "creates" the real configuration based off of the simpler form, which introduces the possibility of leaving the SP itself alone. That also makes it simple to keep supporting config reload at runtime, since the simple format wouldn't ever be loaded directly. The only downside would be the extra generation "step", but it doesn't seem that difficult.

Virtualization

Most of the complexity now comes from the support for virtualization of SPs and application overrides for virtual hosts or paths. It would be really simple to dump all of that, but that might be going too far and prevent significant use of this simpler configration.

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)

On non-IIS, this should all be optional (unless entityID override used). For those cases, the information to associate with the current request should be derivable in the same way it is now, which is outside the configuration of the SP proper. So this This effectively replaces the ISAPI material plus provides for generation of a minimal RequestMap plus ApplicationOverrides with virtual entityID at either the vhost or vhost + path level.None of this addresses the RequestMap itself, which is a harder problem, but separates that piece from the applicationId -> ApplicationOverride function of the current RequestMap.

RequestMapper / Native Commands

The ideal would be to support both a simpler format for IIS and allow a stand-alone XML file with the existing format. The problem with that is the need to "combine" that information with the applicationId mapping information derived from the virtual host section. Since we're going for "simpler", I'm inclined to punt on that and add more material to the virtual host definitions to deal with the rest of the functions of the RequestMap.

Native command support for Apache and NSAPI would remain as is, by wrapping a "generated" XML RequestMap as they do now. So the goal here is only for an alternative syntax that would allow for the generation of that XML.

The sanest way of structuring this that I can think of, which actually introduces an interesting construct that the XML doesn't handle, is to have a set of "named" sections defining the RequestMap properties to attach, and then link to those sections from within the virtual host sections based on the path information to apply them to.

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.

Strawman Examples

[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
maxRefreshDelay=28800
maxValidityInterval=604800
certificate=incommon.pem

[SWITCH]
url=http://metadata.aai.switch.ch/metadata.switchaai.xml
backingFilePath=metadata.switchaai.xml
minRefreshDelay=600
maxRefreshDelay=3600
maxValidityInterval=604800
authority=SWITCHaaiRootCA.crt.pem
verifyDepth=5

; 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"

; 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"