nameID mutiple activationCondition per SP based on different src Attribute

[Jehan PROCACCIA]

Ok then,  I moved UPwards in 1st position [1]  my positive condition for specific SPs and the according attributeSourceIds
but to no avail , samlTracer for those SPs still shows  a transient NameID : 

  <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
...
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                          >AAdzZWNyZX.....Dtk8xdXEkdKQusTknO+vVtjbiv8wIiqOvOOc10s=</saml2:NameID>

I guess I'll have to set logs in debug to find out how the IDP parses my conditions, but this one is in heavy production, I will probably have to duplicate the VM in order to debug without interruptions .  


[1] 
<!-- SAML 2 NameID Generation -->
    <util:list id="shibboleth.SAML2NameIDGenerators">

          <!-- 1st condition SAML 2 sifi-recette OP 9.3 jehan -->
        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
        p:omitQualifiers="true"
        p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
        p:attributeSourceIds="#{ {'uid', 'mail'} }">
        <property name="activationCondition">
                <bean parent="shibboleth.Conditions.RelyingPartyId" >
                <constructor-arg name="candidates">
                         <list>
                        <value>https://sp2.domain.fr/shibboleth</value>
                        <value>https://sp3.dom.eu</value>
                       </list>
                </constructor-arg>
                </bean>
        </property>
        </bean>

<-- 2nd case, generate Transient for all !? --> 
   <ref bean="shibboleth.SAML2TransientGenerator" />

<-- 3rd case , awkward treatment for Microsoft --> 

  <!-- Persistent ID Generator for all entities except Microsoft -->
    <bean parent="shibboleth.SAML2PersistentGenerator">
        <property name="activationCondition">
            <bean parent="shibboleth.Conditions.NOT">
                <constructor-arg>
                    <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{'urn:federation:MicrosoftOnline'}}" />
                </constructor-arg>
            </bean>
        </property>
        </bean>

         <!-- Microsoft requires a custom Persistent ID Generator that sends the AD GUID -->
         <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:candidates="#{{'urn:federation:MicrosoftOnline'}}" />
                </property>
        </bean>


why It didn't match that 1rst condition.... ? debug will probably let me know . 
but please confirm me that I can have multiple reference to  <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

regarding the "NOT" condition for c:candidates="#{{'urn:federation:MicrosoftOnline'}}" and attributeSourceIds="#{ {'ImmutableID'} }"
I guess it's kind of the same pb => order , I hope debug will let me know too ... but at least for that one it does works fine . 

Thanks .

----- Mail original -----
De: "Cantor, Scott via users" <users at shibboleth.net>
À: "Shib Users" <users at shibboleth.net>
Cc: "Cantor, Scott" <cantor.2 at osu.edu>
Envoyé: Lundi 19 Septembre 2022 18:54:32
Objet: Re: nameID mutiple activationCondition per SP based on different src Attribute

It runs them in order, and whatever conditions are attached will execute, and the first one that's active for whichever Format it's trying to use is what will be used.

If it's not working, your conditions are simply not correct and it's picking an earlier one that shouldn't be active but is, or disallowing the one you want that should be active but isn't.

Using NOTs is a pretty good way to ensure that you get the wrong answer, particularly if they're early in the chain. You should in most cases always use positively oriented conditions, not negated ones. You want special cases up front (if RP is X, Y, Z) and then the general ones afterward that just activate by default.

It's not like filter rules where they all run and combine, only one matters.
	
-- Scott


-- 
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net