Disable NameIDGenerator for specificy relyingParty

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

Disable NameIDGenerator for specificy relyingParty

Ignacio Amoeiro Bosch
Hello,

I'm trying to disable NameIDGenerator for an specific Relying Party Id unsucessfully.

What I have tried, is in saml-nameid.xml added:

    <bean parent="shibboleth.SAML2PersistentGenerator">
                <property name="activationCondition">
                    <bean parent="shibboleth.Conditions.NOT">
                        <constructor-arg>
                            <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="urn:federation:MicrosoftOnline" />
                        </constructor-arg>
                    </bean>
                </property>
            </bean>


Just after  <ref bean="shibboleth.SAML2PersistentGenerator" />


What I'm doing wrong?

As a workaround, I have filtered the sourceAttribute used by the SAMLPersitentGenerator in attribute-filter.xml

Regards
--
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: Disable NameIDGenerator for specificy relyingParty

Peter Schober
* Ignacio Amoeiro Bosch <[hidden email]> [2020-05-22 08:48]:
> c:candidate="urn:federation:MicrosoftOnline"

And M$ really requires persistent NameIDs from you, specifically?

> As a workaround, I have filtered the sourceAttribute used by the
> SAMLPersitentGenerator in attribute-filter.xml

Interesting. I thought persistent NameID (and only those) worked on
/unreleased/ attributes? Because it wouldn't make (privacy) sense to
/also/ release the source attribute to the SP verbatim.

So IMO there's no way to prevent persistent NameIDs to be sent to an
SP using the attribute filter. Maybe I'm missing something?

-peter
--
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: Disable NameIDGenerator for specificy relyingParty

Ignacio Amoeiro Bosch
Hello,

Yes, MS requires  the Active Directory objectGuid attribute user sent as persistent NameID... I thinks this has been discussed on this list many times, they are not following the standard.


About the filter, also I set this property to false

 property idp.persistentId.useUnfilteredAttributes

Regards



-----Mensaje original-----
De: users <[hidden email]> En nombre de Peter Schober
Enviado el: viernes, 22 de mayo de 2020 17:21
Para: [hidden email]
Asunto: Re: Disable NameIDGenerator for specificy relyingParty

* Ignacio Amoeiro Bosch <[hidden email]> [2020-05-22 08:48]:
> c:candidate="urn:federation:MicrosoftOnline"

And M$ really requires persistent NameIDs from you, specifically?

> As a workaround, I have filtered the sourceAttribute used by the
> SAMLPersitentGenerator in attribute-filter.xml

Interesting. I thought persistent NameID (and only those) worked on /unreleased/ attributes? Because it wouldn't make (privacy) sense to /also/ release the source attribute to the SP verbatim.

So IMO there's no way to prevent persistent NameIDs to be sent to an SP using the attribute filter. Maybe I'm missing something?

-peter
--
For Consortium Member technical support, see https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwiki.shibboleth.net%2fconfluence%2fx%2fcoFAAg&umid=c2b90ee0-9b31-48be-98be-0722859c3dcb&auth=1c980b950b810d2ebe959a136e6fc6796ec23183-841d1768ab9b0ee3beeb986b29e0e1f51395a77f
To unsubscribe from this list send an email to [hidden email]

--
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: Disable NameIDGenerator for specificy relyingParty

Cantor, Scott E.
In reply to this post by Ignacio Amoeiro Bosch
On 5/22/20, 2:48 AM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> What I'm doing wrong?

You're leaving the original one in place running before the conditional one ever matters.

-- 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: Disable NameIDGenerator for specificy relyingParty

Ignacio Amoeiro Bosch
Hi Scott,

What do you mean?

Should I move the activationCondition block before the      <ref bean="shibboleth.SAML2PersistentGenerator" /> ?


Regards

-----Mensaje original-----
De: users <[hidden email]> En nombre de Cantor, Scott
Enviado el: viernes, 22 de mayo de 2020 19:26
Para: Shib Users <[hidden email]>
Asunto: Re: Disable NameIDGenerator for specificy relyingParty

On 5/22/20, 2:48 AM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> What I'm doing wrong?

You're leaving the original one in place running before the conditional one ever matters.

-- Scott




--
For Consortium Member technical support, see https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwiki.shibboleth.net%2fconfluence%2fx%2fcoFAAg&umid=8e912b03-bf28-4a90-84ad-9509d669cf51&auth=1c980b950b810d2ebe959a136e6fc6796ec23183-102eb2be00c7db86a1065e5d2446bf834487c9e1
To unsubscribe from this list send an email to [hidden email]

--
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: Disable NameIDGenerator for specificy relyingParty

Cantor, Scott E.
On 5/22/20, 1:54 PM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> Should I move the activationCondition block before the      <ref bean="shibboleth.SAML2PersistentGenerator" /> ?

Yes. Lists are always ordered. That's why they're expressed as a list and not a set or some other unordered collection type.

-- 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: Disable NameIDGenerator for specificy relyingParty

Ignacio Amoeiro Bosch
Hi,

I  swaped, but still not working. It is still triggering the Persistentent generator instead of the AtributeSourcedGenerator.



This is the list content:


  <util:list id="shibboleth.SAML2NameIDGenerators">

            <bean parent="shibboleth.SAML2PersistentGenerator">
                <property name="activationCondition">
                    <bean parent="shibboleth.Conditions.NOT">
                        <constructor-arg>
                            <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="urn:federation:MicrosoftOnline" />
                        </constructor-arg>
                    </bean>
                </property>
            </bean>


        <ref bean="shibboleth.SAML2PersistentGenerator" />


    <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
              p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
              p:attributeSourceIds="#{ {'ImmutableID'} }">
        <property name="activationCondition">
            <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="urn:federation:MicrosoftOnline" />
        </property>
    </bean>



    </util:list>



-----Mensaje original-----
De: users <[hidden email]> En nombre de Cantor, Scott
Enviado el: viernes, 22 de mayo de 2020 20:13
Para: Shib Users <[hidden email]>
Asunto: Re: Disable NameIDGenerator for specificy relyingParty

On 5/22/20, 1:54 PM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> Should I move the activationCondition block before the      <ref bean="shibboleth.SAML2PersistentGenerator" /> ?

Yes. Lists are always ordered. That's why they're expressed as a list and not a set or some other unordered collection type.

-- Scott


--
For Consortium Member technical support, see https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwiki.shibboleth.net%2fconfluence%2fx%2fcoFAAg&umid=93065d65-44f5-48b6-a8f3-de050acfb3a0&auth=1c980b950b810d2ebe959a136e6fc6796ec23183-de38232b991b77df91b7aebe02225c5854afdefb
To unsubscribe from this list send an email to [hidden email]

--
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: Disable NameIDGenerator for specificy relyingParty

Cantor, Scott E.
On 5/22/20, 2:25 PM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> I  swaped, but still not working. It is still triggering the Persistentent generator instead of the AtributeSourcedGenerator.
> This is the list content:

The attribute sourced plugin is now third in your list, after two others. The first one will run using a default computed or stored ID for all RPs other than O365, and the second one will do the same but globally and is being used.

You need move the attribute sourced version running for O365 first and get rid of the other one with the NOT condition since it will never be hit.

-- 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: Disable NameIDGenerator for specificy relyingParty

Ignacio Amoeiro Bosch
Ok, now is working.

I didn't understand well how spring framework Works.

So, to clarify my self,

Has the same effect:

<ref bean="shibboleth.SAML2PersistentGenerator" />

than:

<bean parent="shibboleth.SAML2PersistentGenerator"/>


?


-----Mensaje original-----
De: users <[hidden email]> En nombre de Cantor, Scott
Enviado el: viernes, 22 de mayo de 2020 20:31
Para: Shib Users <[hidden email]>
Asunto: Re: Disable NameIDGenerator for specificy relyingParty

On 5/22/20, 2:25 PM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> I  swaped, but still not working. It is still triggering the Persistentent generator instead of the AtributeSourcedGenerator.
> This is the list content:

The attribute sourced plugin is now third in your list, after two others. The first one will run using a default computed or stored ID for all RPs other than O365, and the second one will do the same but globally and is being used.

You need move the attribute sourced version running for O365 first and get rid of the other one with the NOT condition since it will never be hit.

-- Scott


--
For Consortium Member technical support, see https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwiki.shibboleth.net%2fconfluence%2fx%2fcoFAAg&umid=9c3cf50c-c799-4779-8078-71a3246c01a0&auth=1c980b950b810d2ebe959a136e6fc6796ec23183-52cbdcb3baec1a7b42c5a829c87bab1681a63d3d
To unsubscribe from this list send an email to [hidden email]

--
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: Disable NameIDGenerator for specificy relyingParty

Cantor, Scott E.
On 5/22/20, 2:57 PM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> I didn't understand well how spring framework Works.

That's why the IdP documentation starts by pointing to the Spring XML docs.

> So, to clarify my self,
> Has the same effect:
> <ref bean="shibboleth.SAML2PersistentGenerator" />
> than:
> <bean parent="shibboleth.SAML2PersistentGenerator"/>

Functionally, but the former uses an existing object and the latter creates a new one based on the bean definition of the parent. In this particular case that means one extra object created, relatively insignificant. In other cases it could be a major difference.

-- 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: Disable NameIDGenerator for specificy relyingParty

Ignacio Amoeiro Bosch
Ok, thanks for the explanation.

Yes, I knew that spring XML documentation is important to understand shibboleth configuration.

Thanks again for all

-----Mensaje original-----
De: users <[hidden email]> En nombre de Cantor, Scott
Enviado el: viernes, 22 de mayo de 2020 21:08
Para: Shib Users <[hidden email]>
Asunto: Re: Disable NameIDGenerator for specificy relyingParty

On 5/22/20, 2:57 PM, "users on behalf of Ignacio Amoeiro Bosch" <[hidden email] on behalf of [hidden email]> wrote:

> I didn't understand well how spring framework Works.

That's why the IdP documentation starts by pointing to the Spring XML docs.

> So, to clarify my self,
> Has the same effect:
> <ref bean="shibboleth.SAML2PersistentGenerator" />
> than:
> <bean parent="shibboleth.SAML2PersistentGenerator"/>

Functionally, but the former uses an existing object and the latter creates a new one based on the bean definition of the parent. In this particular case that means one extra object created, relatively insignificant. In other cases it could be a major difference.

-- Scott


--
For Consortium Member technical support, see https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwiki.shibboleth.net%2fconfluence%2fx%2fcoFAAg&umid=5fd8e05f-3f1a-4c2c-8811-3de4aa7f46c0&auth=1c980b950b810d2ebe959a136e6fc6796ec23183-aacf235d17dc9797a374bef0caee5ae5dbc573bf
To unsubscribe from this list send an email to [hidden email]

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