Page Comparison

...

The other option, which will be noted in the examples here, is to wire up by hand specific support for a particular tag doing a specific thing. This isn’t obvious, but it follows a basic pattern and the specific wiring needed is shown in the examples. Note that this doesn’t obviate the risk of specific tags being injected by metadata sources, but in some cases this risk is further mitigated by a lack of benefit in doing so by that source. Some settings just don’t gain somebody anything to manipulate.

Signing Key Selection

It is not generally useful practice to use more than one signing key at a time (consider where they’re all stored, and the probability that if one were compromised that the rest would somehow not be?). However, this occasionally becomes necessary either during a transition to a new key, or an adjustment that becomes necessary due to constraints imposed by a particular SP regarding size or changes to security policy, for example, the transition away from SHA-1 certificates though SAML itself isn’t affected by that issue at all when implemented compliantly.

The goal of this example is to default the system to signing with a particular “current” key/certificate, but tag specific SPs that require the use of a different key or certificate.

Security Configuration Beans

Because this has never been a common thing for a Shibboleth IdP to do, there isn’t a clean/simple way to control the key. It’s part of a much larger set of objects that make up the so-called Security Configuration setting, which includes not only keys but also algorithm controls.

Signing Credentials

First you need to actually define beans in credentials.xml that load the relevant key and certificate to make up each individual signing credential. In this real world example, the “first” credential has been replaced at some point and in its place two new keys were deployed using properties to locate the files and password. The most important points are that you need to be sure to alias shibboleth.DefaultSigningCredential to the one to use by default, and the shibboleth.SigningCredentials bean needs to reference all of them.

<util:list id="shibboleth.SigningCredentials">
    <ref bean="my.SigningCredential.2" />
    <ref bean="my.SigningCredential.3" />
</util:list>

<alias alias="shibboleth.DefaultSigningCredential" name="my.SigningCredential.2" />

<bean id="my.SigningCredential.2"
    class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
    p:privateKeyResource="%{idp.signing.key.2}"
    p:privateKeyPassword="%{idp.signing.password}"
    p:certificateResource="%{idp.signing.cert.2}"
    p:entityId-ref="entityID" />

<bean id="my.SigningCredential.3"
    class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
    p:privateKeyResource="%{idp.signing.key.3}"
    p:privateKeyPassword="%{idp.signing.password}"
    p:certificateResource="%{idp.signing.cert.3}"
    p:entityId-ref="entityID" />

Security Configurations

Second, you define a separate security configuration in relying-party.xml making use of the non-default key. In this example, several built-in beans are used to simplify the definitions. Only the signing key is overridden.

<bean id="my.SecurityConfig.Exception" parent="shibboleth.DefaultSecurityConfiguration">
    <property name="signatureSigningConfiguration">
        <bean parent="shibboleth.SigningConfiguration.SHA256" p:signingCredentials-ref="my.SigningCredential.3" />
    </property>
</bean>

Adding Tag Support

As described in the introduction, you can do this either globally as documented with the .MDDriven profile bean suffix or just add support for this specific tag:

...

In English, what the strategy bean says is “Look in the metadata for a standardized cross-profile tag named “http://shibboleth.net/ns/profiles/securityConfiguration” whose value is the name of a bean of type net.shibboleth.idp.profile.config.SecurityConfiguration. In other words, the tag can’t really be the configuration in the same way as a boolean or string valued setting but is the name of the bean supplying the configuration.

Metadata

Local Metadata

When you control the metadata (or script it, etc.), then you would tag an SP to trigger use of the non-default key like so:

<md:EntityDescriptor entityID="https://paininmybutt.example.org/sp">
  <md:Extensions>
    <mdattr:EntityAttributes>
      <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="http://shibboleth.net/ns/profiles/securityConfiguration">
        <saml:AttributeValue>my.SecurityConfig.Exception</saml:AttributeValue>
      </saml:Attribute>
    </mdattr:EntityAttributes>
  </md:Extensions>
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  </md:SPSSODescriptor>
...
</md:EntityDescriptor>

Remote Metadata

For a remote metadata source, you will typically want two filters, one to strip anthing undesired from the feed and another to add the tag you want. In this example, anything other than so-called “entity category” tags are removed before adding the exception tag.

          <!-- Strip most existing tags. -->
          <MetadataFilter xsi:type="EntityAttributes">
            <AttributeFilterScript>
                <Script>
                <![CDATA[
                input.getName().equals("http://macedir.org/entity-category");
                ]]>
                </Script>
            </AttributeFilterScript>
          </MetadataFilter>

          <MetadataFilter xsi:type="EntityAttributes">
            <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="http://shibboleth.net/ns/profiles/securityConfiguration">
              <saml:AttributeValue>my.SecurityConfig.Exception</saml:AttributeValue>
            </saml:Attribute>

            <Entity>https://paininmybutt.example.org/sp</Entity>
          </MetadataFilter>

Of course any number of <Entity> tags can be added to tag other SPs as needed, making all of this set up worth it because of the ease of maintenance later.