Using metadata-driven overrides and relying party config

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Using metadata-driven overrides and relying party config

Michael Grady
So when  one turns on support for metadata-driven overrides in relying-party.xml, does that mean you need to use either metadata-driven for a given SP, or an override in relying-party.xml, but not both? Can they be combined?

Clearly its best to be consistent and not use both in general, at least not for the same SP.  I do know from a recent test that setting 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.   So one cannot use both for a situation like that. But I'm not clear if any SP-specific override in relying party causes all metadata-driven overrides  to be ignored or not.

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



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using metadata-driven overrides and relying party config

Cantor, Scott E.
On 1/14/21, 11:31 AM, "users on behalf of Michael Grady" <[hidden email] on behalf of [hidden email]> wrote:

>    So when  one turns on support for metadata-driven overrides in relying-party.xml, does that mean you need to use
> either metadata-driven for a given SP, or an override in relying-party.xml, but not both? Can they be combined?

They should combine properly [1], but that code is tricky and I'm sure there may be bugs. The reason it's suppsoed to work is that there's a chain of beans involved and Spring is *supposed* to apply a parent bean's properties before the child's properties. That should result in the static setter being called after the setter that injects the function lookup, so the static setter "replaces" the dynamic function with a constant/static function.

>  Clearly its best to be consistent and not use both in general, at least not for the same SP.

I do it in some cases but I haven't exhaustively tested or tried to combine specific metadata signals with static signals for the same setting. I just tested the basic behavior to see if it matched what Spring claims it does.

> I do know from a recent test that setting 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.

-- Scott

[1] I define properly as "the configuration should override the metadata".

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using metadata-driven overrides and relying party config

Michael Grady


On Jan 14, 2021, at 11:12 AM, Cantor, Scott <[hidden email]> wrote:

I do know from a recent test that setting 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.




--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using metadata-driven overrides and relying party config

Cantor, Scott E.
On 1/14/21, 2:29 PM, "users on behalf of Michael Grady" <[hidden email] on behalf of [hidden email]> wrote:

>    but then having an override section that applies the following:

>                       <bean parent="SAML2.SSO"

Wrong parent. *Nothing* can be using metadata unless you add the MDDriven suffix to the parent bean name.

-- Scott



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using metadata-driven overrides and relying party config

Michael Grady


On Jan 14, 2021, at 2:06 PM, Cantor, Scott <[hidden email]> wrote:

Wrong parent. *Nothing* can be using metadata unless you add the MDDriven suffix to the parent bean name.

Ah, yes. Once one adds it to the DefaultRelying party, one can think of it "turned on" for evreything.  Personally, I think it would be good to have such an on/off switch, and not be required at the level it is, but a good reminder that it is. This was (supposed) to be a quick test of throwing those options on for that SP, so clearly didn't think thru all the ramifications of doing that. This will "burn it into memory" now :-)

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




--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using metadata-driven overrides and relying party config

Cantor, Scott E.
On 1/14/21, 4:43 PM, "users on behalf of Michael Grady" <[hidden email] on behalf of [hidden email]> wrote:

>    Ah, yes. Once one adds it to the DefaultRelying party, one can think of it "turned on" for evreything.  Personally, I think
> it would be good to have such an on/off switch, and not be required at the level it is, but a good reminder that it is.

It would have been simple to globally wire it up as a default, but the problem is that opening up to metadata like this is a big, big deal if you don't take care and protect against external metadata tag injection, so that wasn't really an option.

-- Scott



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using metadata-driven overrides and relying party config

Michael Grady


> On Jan 14, 2021, at 3:47 PM, Cantor, Scott <[hidden email]> wrote:
>
> On 1/14/21, 4:43 PM, "users on behalf of Michael Grady" <[hidden email] on behalf of [hidden email]> wrote:
>
>>   Ah, yes. Once one adds it to the DefaultRelying party, one can think of it "turned on" for evreything.  Personally, I think
>> it would be good to have such an on/off switch, and not be required at the level it is, but a good reminder that it is.
>
> It would have been simple to globally wire it up as a default, but the problem is that opening up to metadata like this is a big, big deal if you don't take care and protect against external metadata tag injection, so that wasn't really an option.
>
> -- Scott
>


One would hope that Federations would prevent the addition of entity attributes starting with a namespace that is clearly  not theirs. But yes, any "global" setting should come with a warning giving an example of how to be sure metadata not under your full control should have entity attributes "with given prefixes filtered out before adding in your own.

Not suggesting it should be in place of the per-profile bean setting, but akin to having the "idp.encryption.optional" property, only use if you know what you are doing.

Of course, if one just sticks to putting all overrides into the metadata, it doesn't matter.

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



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using metadata-driven overrides and relying party config

Michael Grady
In reply to this post by Cantor, Scott E.


On Jan 14, 2021, at 2:06 PM, Cantor, Scott <[hidden email]> wrote:

but then having an override section that applies the following:

                     <bean parent="SAML2.SSO" 

Wrong parent. *Nothing* can be using metadata unless you add the MDDriven suffix to the parent bean name.

And to bring this thread full circle, it does work fine once the override references the MDDriven bean. Security config from the metadata entity attribute, and the "what to sign" from the override. Thanks!

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




--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]