The new config supports:

Multiple search paths can be provided.

At runtime any requests for a missing application ID will attempt to find a file in the search path named id-override.xml rooted in an ApplicationOverride element and load it on the fly.

This will be considered experimental for the time being as we don't have a lot of time to test it thoroughly. It doesn't impact anything if it isn't used so it's low risk.

I don't think I can take on reloadable files, but I think a basic dynamic "look in directory for file named <something>" option should be doable. That's a slight improvement over just allowing external files since it would let people add new ones on the fly, just not with change support.

They have currently about 100 SPs (about 20-50 per server) and 150-300 will follow in the coming years. The process to create new SPs/web servers is automated. Currently the use a config like the following one where for each virtual SP everything is typicallz the same except hostname, entityID and certificate:

<code>
<SPConfig>
<RequestMapper type="Native">
<RequestMap applicationId="default">
<Host name="ew-stage.geo.example-org.ch"
applicationId="ew-stage.geo.example-org.ch" />
<Host name="ew-stage.aegyptologie.philhist.example-org.ch"
applicationId="ew-stage.aegyptologie.philhist.example-org.ch" />
<Host name="ew-stage.philnat.example-org.ch"
applicationId="ew-stage.philnat.example-org.ch" />
<Host name="ew-stage.nursing.example-org.ch"
applicationId="ew-stage.nursing.example-org.ch" />
</RequestMap>
</RequestMapper>
<ApplicationDefaults id="default"
metadataAttributePrefix="Meta-"
REMOTE_USER="persistent-id targeted-id uniqueID"
signing="back"
requireTransportAuth="false"
entityID="https://its-web-012.its.example-org.ch/shibboleth"
homeURL="https://its-web-012.its.example-org.ch/Shibboleth.sso/Session">
<Sessions lifetime="28800"
timeout="3600"
relayState="ss:mem"
checkAddress="false"
consistentAddress="true"
handlerSSL="false"
cookieProps="http">
<SSO discoveryProtocol="SAMLDS"
discoveryURL="https://wayf.switch.ch/SWITCHaai/WAYF">SAML2</SSO>
<Logout>Local</Logout>
[...]
</Sessions>
<Errors access="accessError.html"
helpLocation="https://www.switch.ch/aai/help"
logoLocation="https://www.switch.ch/aai/design/images/SWITCHaai.gif"
styleSheet="https://www.switch.ch/aai/design/shib-error.css"
supportContact="wsym-its@example-org.ch" />
<MetadataProvider type="XML"
validate="true"
uri="http://metadata.aai.switch.ch/metadata.switchaai.xml"
backingFilePath="metadata.switchaai.xml"
reloadInterval="3600">
<MetadataFilter type="RequireValidUntil"
maxValidityInterval="604800" />
<MetadataFilter type="Signature">
<TrustEngine type="StaticPKIX"
certificate="SWITCHaaiRootCA.crt.pem"
verifyDepth="2"
checkRevocation="fullChain"
policyMappingInhibit="true"
anyPolicyInhibit="true">
<TrustedName>SWITCHaai Metadata Signer</TrustedName>
<PolicyOID>2.16.756.1.2.6.7</PolicyOID>
</TrustEngine>
</MetadataFilter>
</MetadataProvider>
[...]
<ApplicationOverride id="ew-stage.geo.example-org.ch"
entityID="https://ew-stage.geo.example-org.ch/shibboleth">
<Sessions lifetime="28800"
timeout="3600"
relayState="ss:mem"
checkAddress="false"
consistentAddress="true"
handlerSSL="false"
cookieProps="http">
</Sessions>
<CredentialResolver type="File"
keyName="Active"
key="/etc/shibboleth/ew-stage.geo.example-org.ch.sp-key.pem"
certificate="/etc/shibboleth/ew-stage.geo.example-org.ch.sp-cert.pem" />
</ApplicationOverride>
<ApplicationOverride id="ew-stage.aegyptologie.philhist.example-org.ch"
entityID="https://ew-stage.aegyptologie.philhist.example-org.ch/shibboleth">
<Sessions lifetime="28800"
timeout="3600"
relayState="ss:mem"
checkAddress="false"
consistentAddress="true"
handlerSSL="false"
cookieProps="http">
</Sessions>
<CredentialResolver type="File"
keyName="Active"
key="/etc/shibboleth/ew-stage.aegyptologie.philhist.example-org.ch.sp-key.pem"
certificate="/etc/shibboleth/ew-stage.aegyptologie.philhist.example-org.ch.sp-cert.pem" />
</ApplicationOverride>
<ApplicationOverride id="ew-stage.philnat.example-org.ch"
entityID="https://ew-stage.philnat.example-org.ch/shibboleth">
<Sessions lifetime="28800"
timeout="3600"
relayState="ss:mem"
checkAddress="false"
consistentAddress="true"
handlerSSL="false"
cookieProps="http">
</Sessions>
<CredentialResolver type="File"
keyName="Active"
key="/etc/shibboleth/ew-stage.philnat.example-org.ch.sp-key.pem"
certificate="/etc/shibboleth/ew-stage.philnat.example-org.ch.sp-cert.pem" />
</ApplicationOverride>
<ApplicationOverride id="ew-stage.nursing.example-org.ch"
entityID="https://ew-stage.nursing.example-org.ch/shibboleth">
<Sessions lifetime="28800"
timeout="3600"
relayState="ss:mem"
checkAddress="false"
consistentAddress="true"
handlerSSL="false"
cookieProps="http">
</Sessions>
<CredentialResolver type="File"
keyName="Active"
key="/etc/shibboleth/ew-stage.nursing.example-org.ch.sp-key.pem"
certificate="/etc/shibboleth/ew-stage.nursing.example-org.ch.sp-cert.pem" />
</ApplicationOverride>
</ApplicationDefaults>
[...]
</SPConfig>
</code>

For them it would be great if there was a basic configuration in shibboleth2.xml and external files for each virtual SP (containing the "diff" compared ot the basic config in form of an ApplicationOverride element). But maybe there is also a more elegant solution foreseen in SPv3 .

That, and I suspect that given that this probably will not be made dynamic, that it doesn't actually do anything useful.

Any solution I could come up with would still involve touching shibboleth2.xml (because that's the only way to know an external file has been added), and at that point, why bother? That's what I'm trying to understand/verify.

But yes, mainly I continue to believe overrides are a bad idea and that our focus should be understanding the use cases for them and gradually eliminating them.

I may be mischannelling here, but I think the question he would like to understand is what your unis are putting into the ApplicationOverride Element that cannot be done better in other ways. (For instance by using Content Settings or the relying party override he added for V3)