Using metadata-driven overrides and relying party config

[Michael Grady]

> On Jan 14, 2021, at 11:12 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> I do know from a recent test that setting http://shibboleth.net/ns/profiles/securityConfiguration <http://shibboleth.net/ns/profiles/securityConfiguration>  to ties into a new 
>> signing cert in the metadata for a SP does not work if there is then a RP override that overrdies what to sign.
> 
> Maybe you're expecting the opposite, and the opposite is not the intended behavior. The static configuration SHOULD override the metadata. That is what I would expect as a deployer.

The "combo" that does not appear to work is having this in the SP metadata:

    <md:Extensions xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
      <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
        <saml2:Attribute Name="http://shibboleth.net/ns/profiles/securityConfiguration" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
          <saml2:AttributeValue>NewSecurityConfig2020to2040</saml2:AttributeValue>
        </saml2:Attribute>
      </mdattr:EntityAttributes>
    </md:Extensions>

which ties into this in relying party:

	<bean id="NewSecurityConfig2020to2040" parent="shibboleth.DefaultSecurityConfiguration">
	    <property name="signatureSigningConfiguration">
	        <bean parent="shibboleth.SigningConfiguration.SHA256" p:signingCredentials-ref="NewSigningCredential2020to2040" />
	    </property>
	</bean>

but then having an override section that applies the following:

                   <bean parent="SAML2.SSO" 
                        p:encryptAssertions="false" 
                        p:signResponses="false" 
                        p:signAssertions="true" />


Having the latter, causes the IdP to go back to using the default sinning cert config, not the new one.  Probably not surprising since both are "playing in the space of the the signing configuration".

(The only reason that latter relying party override was used was because it was already there for related SPs, so it was "easy' to add this SP's entityID to that override to see if those settings fixed a problem or not. That's when I saw that the signing cert being used went from the new one back to the default one. Easy enough to just put it all into the metadata now that I know that.)

--
Michael A. Grady
IAM Architect, Unicon, Inc.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210114/9e92cb57/attachment.htm>