SPRoadmapSimplerConfig
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
[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"