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