<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2021, at 11:12 AM, Cantor, Scott <<a href="mailto:cantor.2@osu.edu" class="">cantor.2@osu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">I do know from a recent test that setting<span class="Apple-converted-space"> </span><a href="http://shibboleth.net/ns/profiles/securityConfiguration" class="">http://shibboleth.net/ns/profiles/securityConfiguration</a><span class="Apple-converted-space"> </span> to ties into a new<span class="Apple-converted-space"> </span><br class="">signing cert in the metadata for a SP does not work if there is then a RP override that overrdies what to sign.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">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.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></div></blockquote><br class=""></div><div>The "combo" that does not appear to work is having this in the SP metadata:</div><div><br class=""></div><div><div> <md:Extensions xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"></div><div> <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"></div><div> <saml2:Attribute Name="<a href="http://shibboleth.net/ns/profiles/securityConfiguration" class="">http://shibboleth.net/ns/profiles/securityConfiguration</a>" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"></div><div> <saml2:AttributeValue>NewSecurityConfig2020to2040</saml2:AttributeValue></div><div> </saml2:Attribute></div><div> </mdattr:EntityAttributes></div><div> </md:Extensions></div></div><div class=""><br class=""></div>which ties into this in relying party:<div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><bean id="NewSecurityConfig2020to2040" parent="shibboleth.DefaultSecurityConfiguration"></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> <property name="signatureSigningConfiguration"></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> <bean parent="shibboleth.SigningConfiguration.SHA256" p:signingCredentials-ref="NewSigningCredential2020to2040" /></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> </property></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></bean></div><div class=""><br class=""></div><div class="">but then having an override section that applies the following:</div><div class=""><br class=""></div><div class=""><div class=""> <bean parent="SAML2.SSO" </div><div class=""> p:encryptAssertions="false" </div><div class=""> p:signResponses="false" </div><div class=""> p:signAssertions="true" /></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Having the latter, causes the IdP to go back to using the default sinning cert config, not the new one. <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Probably not surprising since both are "playing in the space of the the signing configuration".</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class="">(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.)</div><div class=""><br class=""></div><div class="">
<div>--<br class="">Michael A. Grady<br class="">IAM Architect, Unicon, Inc.</div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>