wish list: ability to define reusable blocs in SP configuration

[Guillaume Rousse]

Hello.

We are currently testing the latest 3.0 release of the SP. I was 
particulary interested by the change regarding related to reducing the 
needs of ApplicationOverride elements in configuration files. 
Unfortunatly, it doesn't fit our needs :(

We deploy SP on authenticating reverse proxies, meaning each SP manage a 
lot of different applications (approximatively 40 currently), each in a 
different virtual host. What makes those applications different is the 
exact set of trusted IdPs:
- french education-research federation only
- french education-research federation + a single non-federated IdP
- eduGAIN federation
- eduGAIN federation + a single non-federated IdP

For each of those set, we have to define a different list of metadata 
files, and a different discovery service URL. So, whatever set is 
defined at the default level, we have cumbersome (and redundant) 
additional declarations in individual <ApplicationOverride> elements, ie:

<ApplicationDefaults entityID="https://app1">
   <SSO
     discoveryProtocol="SAMLDS"
     discoveryURL="https://discovery1">SAML2</SSO>

   <MetadataProvider type="XML"
     url="https://metadata1.xml"
     backingFilePath="/var/cache/shibboleth/metadata1.xml">
     <MetadataFilter type="Signature" certificate="cert1.crt"/>
   </MetadataProvider>

   <ApplicationOverride id="app2" entityID="https://app2">
     # override needed because of another non-federated IdP
     <SSO
       discoveryProtocol="SAMLDS"
       discoveryURL="https://discovery2">SAML2</SSO>
     <MetadataProvider type="Chaining">
       <MetadataProvider type="XML"
         url="https://metadata1.xml"
         backingFilePath="/var/cache/shibboleth/metadata1.xml">
         <MetadataFilter type="Signature" certificate="cert1.crt"/>
       </MetadataProvider>
       <MetadataProvider type="XML"
         url="https://metadata2.xml"
         backingFilePath="/var/cache/shibboleth/metadata2.xml">
         <MetadataFilter type="Signature" certificate="cert2.crt"/>
       </MetadataProvider>
     </MetadataProvider>
  </ApplicationOverride>

   <ApplicationOverride id="app3" entityID="https://app3">
     # override needed because of another non-federated IdP
     <SSO
       discoveryProtocol="SAMLDS"
       discoveryURL="https://discovery2">SAML2</SSO>
     <MetadataProvider type="Chaining">
       <MetadataProvider type="XML"
         url="https://metadata1.xml"
         backingFilePath="/var/cache/shibboleth/metadata1.xml">
         <MetadataFilter type="Signature" certificate="cert1.crt"/>
       </MetadataProvider>
       <MetadataProvider type="XML"
         url="https://metadata2.xml"
         backingFilePath="/var/cache/shibboleth/metadata2.xml">
         <MetadataFilter type="Signature" certificate="cert2.crt"/>
       </MetadataProvider>
     </MetadataProvider>
  </ApplicationOverride>

</ApplicationDefaults>

I had a quick look also at ExternalApplicationOverrides element, in 
order to reuse the same external configuration fragment for multiple 
applications, but it doesn't seem to be the indended use case, as this 
element define a search path where the applications expect to find files 
dedicated to each applications.

What would really makes this configuration easier to maintain would be 
the ability to define reusable blocs of configuration settings, and then 
refer to them later in the configuration. For instance, with this 
ability restricted to metadata sets:

<MetadataSets>
   <MetadataSet id="md1">
     <MetadataProvider type="XML"
       url="https://metadata1.xml"
       backingFilePath="/var/cache/shibboleth/metadata1.xml">
       <MetadataFilter type="Signature" certificate="cert1.crt"/>
     </MetadataProvider>
   </MetadataSet>

   <MetadataSet id="md2">
     <MetadataProvider type="Chaining">
       <MetadataProvider type="XML"
         url="https://metadata1.xml"
         backingFilePath="/var/cache/shibboleth/metadata1.xml">
         <MetadataFilter type="Signature" certificate="cert1.crt"/>
       </MetadataProvider>
       <MetadataProvider type="XML"
         url="https://metadata2.xml"
         backingFilePath="/var/cache/shibboleth/metadata2.xml">
         <MetadataFilter type="Signature" certificate="cert2.crt"/>
       </MetadataProvider>
     </MetadataProvider>
   </MetadataSet>
</MetadataSets>

<ApplicationDefaults entityID="https://app1">
   <SSO discoveryProtocol="SAMLDS"
     discoveryURL="https://discovery1">SAML2</SSO>

   <MetadataSet ref="md1"/>

   <ApplicationOverride id="app2" entityID="https://app2">
     # override needed because of another non-federated IdP
     <SSO discoveryProtocol="SAMLDS"
       discoveryURL="https://discovery2">SAML2</SSO>
      <MetadataSet ref="md2"/>
  </ApplicationOverride>

   <ApplicationOverride id="app3" entityID="https://app3">
     # override needed because of another non-federated IdP
     <SSO discoveryProtocol="SAMLDS"
       discoveryURL="https://discovery2">SAML2</SSO>
    <MetadataSet ref="md2"/>
  </ApplicationOverride>

</ApplicationDefaults>

I'm ready to fill an formal enhancement request on Jira for this feature 
if it can be considered feasable and useful.

Regards.
-- 
Guillaume Rousse
Pôle SSI

Tel: +33 1 53 94 20 45
www.renater.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3637 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20180806/924ffa6c/attachment.p7s>