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 should be expressable in simple form.
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 because of the need to reference hostname(s).
A simpler format might also be "pluggable" into standard config.
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.
AssertionConsumerService / Logout / Misc SAML endpoints
Hardwire them, 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, probably can hardwire the rest.
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.
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
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).
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 plugin.