Disable NameIDGenerator for specificy relyingParty

Ignacio Amoeiro Bosch ignacio.amoeiro at extern.ibsalut.es
Fri May 22 15:45:21 UTC 2020


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 


-----Mensaje original-----
De: users <users-bounces at shibboleth.net> En nombre de Peter Schober
Enviado el: viernes, 22 de mayo de 2020 17:21
Para: users at shibboleth.net
Asunto: Re: Disable NameIDGenerator for specificy relyingParty

* Ignacio Amoeiro Bosch <ignacio.amoeiro at extern.ibsalut.es> [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?

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 users-unsubscribe at shibboleth.net

More information about the users mailing list