nameID mutiple activationCondition per SP based on different src Attribute

[Jehan PROCACCIA]

I finally succeed to cumulate different NameIds for different SPs

I could remove the ActivationCondition.NOT (which seems to be bad practice for general purposes) and play with order of beans in saml-nameid.xml + settings in relying-party.xml as advice before in this thread . 

Now my IDPv4 can send an unspecified format NameID with a specific sourceAttribute to SP1 and a persitent NameID with an other sourceAttribute to SP2, while still providing transient nameID as default for others or  Persistent if requested . 

for the record (to myself) here's how it is configured, let me know if it is still awkward ? 

 <util:list id="shibboleth.SAML2NameIDGenerators">
<!-- uid or mail sourceAttribute for SP1 with unspecified namedid format --> 
 <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
        p:omitQualifiers="true"
        p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
        p:attributeSourceIds="#{ {'uid', 'mail'} }">
        </bean>

<!-- default to transcient for others --> 
<ref bean="shibboleth.SAML2TransientGenerator" />

 <!-- Microsoft (SP2)  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>

   <!-- Persistent ID Generator for all other entities except Microsoft and OP9.6 cf above-->
    <bean parent="shibboleth.SAML2PersistentGenerator">
   </bean>
 </util:list>

</beans>

relying-party 


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

<!-- SP1 (en 3)  overrrides --> 
  <bean id="IMTOP9" parent="RelyingPartyByName" c:relyingPartyIds="#{{'https://sp1.domain.fr', 'https://sp3.domain.fr'}}">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:encryptAssertions="false" p:checkAddress="false" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" p:postAuthenticationFlows="#{ {'attribute-release'} }" />
                </list>
            </property>
        </bean>

   <!-- Microsoft Azure AD overrrides -->
        <bean parent="RelyingPartyByName" c:relyingPartyIds="urn:federation:MicrosoftOnline">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:encryptAssertions="false" />
                </list>
            </property>
        </bean>

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

>    as I replied to Scott in this thread, I guess I'll have to debug this outside
> production, beacause it doesn't seem to be that easy 

It is routine once you understand Format selection, but most people are convinced that somehow the activation conditions have something to do with that, when in fact they have nothing to do with it.

You *start* with the Format as a given, and that's established entirely outside that file you're touching. Until you understand the Format that it wants to use, you can't evaluate what the chain of generators is really doing for that SP.

Once the Format is known, the only generators you have to look at are the ones with that Format, since the rest don't apply.

And then it's almost always an error in attribute resolution or filtering, which is also easy to check separately.

>    I cannot stop/start the service during working hours and it' time
> consuming to wait late evenings to do so . 

None of that requires restarts, only service reloads, but obviously you don't do it in prod anyway. All deployers should have a staging system running identically that can be used to test anything they need to test, and when it comes to this sort of thing, it doesn't even need the keys, merely the config to be able to run aacli.

-- 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