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.

Non-Goals

Hide all uses of XML in the configuration.
Create an alternative to SAML metadata for describing partners.
Provide a GUI or management tools.
Simplify the design of the SP itself or shrink the "footprint".

Existing Configuration Material

"Root" SPConfig

Contains only simple defaulted settings or properties that can be hardcoded.

OutOfProcess/InProcess

A few defaultable or hardcoded settings.
Could skip loading of extensions entirely, or provide a simple mechanism.

ISAPI/Site material probably impossible to avoid.

Listener

Unix and TCP options 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

Generally manipulated as a unit.
Could hardwire in-memory choices or provide an in-memory / ODBC choice with a few critical settings exposed as simple properties.

RequestMapper

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.
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.

ApplicationDefaults/ApplicationOverride

Should aim for reproducing the most important subset of this feature, simple entityID overrides based on vhost, maybe also based on path with suitable assumptions.

Sessions

Anything not hardcoded can be "rolled up" to the application or top level.

SessionInitiator

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 the 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.

Custom Handlers

Useful enough to hardwire or support a few simple properties.

Errors

Mostly hardcoded already, a 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.

MetadataProvider

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.

AttributeExtractor / Resolver / Filter

Seems counter-productive to produce more formats for the existing extractor / filter plugins, and those settings are already in their own files anyway.
Probably unnecessary to support anything beyond simple queries for resolution, so that can be hardwired.

CredentialResolver

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

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.

That 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 hostnames in a [SHIB2:vhost] section could point to dedicated sections for each vhost. Those sections could include settings such as:

IIS site instance ID
aliases to permit (on IIS)
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). 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.

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

Simple Apache Example with Logout

[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

Simple IIS Example

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

EntityID Override Example

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