<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Hello<br></div><div><br data-mce-bogus="1"></div><div>I don't use MFA for now, but if that's a way to make it run as expected, I'll go in that direction .<br data-mce-bogus="1"></div><div>Indeed , I am not convince that replying-party config could be the right way to do that ? <br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I am surprise though that this kind of access control to a Service Provider based on an attribute value is not that much documented <br data-mce-bogus="1"></div><div>I've seen it in <a href="https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509766/ActivationConditions">https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509766/ActivationConditions</a> <br data-mce-bogus="1"></div><div>chapter => Attribute Checking<br>but it's not clear where to apply it, and how to corrolate that to a specific SP for denied access </div><div>If there a simple way to do that " deny acces to a SP based on attribute value" ?  , I take it in the first place <br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>but I would also like to see your sample config to acheive the whole process, as you seem to have done it compeltly even with a messaged returned to users who are rejected ! <br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks for you help . <br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>jehan<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><br><br><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>De: </b>"db--- via users" <users@shibboleth.net><br><b>À: </b>"Shib Users" <users@shibboleth.net><br><b>Cc: </b>"db@alaska.edu" <dabantz@alaska.edu>, "users" <users@shibboleth.net><br><b>Envoyé: </b>Dimanche 7 Décembre 2025 21:38:40<br><b>Objet: </b>Re: how to deny acces to a SP based on attribute value<br></div><br><div data-marker="__QUOTED_TEXT__">We do something similar to deny sign-ins to specific SPs if eduPersonAffiliation is only affiliate - not member/student/faculty/staff. But relying-party is not AFAIK capable of stopping sign in as you want. We create an attribute in resolver to flag stop (based on ePA and entityID of service), then use script in mfa config to set a nextFlow if triggered, and a vm that displays message to user. Details on request.<br><div><div dir="ltr"><div>David.Bantz<span class="Apple-style-span">@Alaska.edu</span><div><span class="Apple-style-span"><br></span></div></div></div><div dir="ltr"><br><blockquote>On Dec 7, 2025, at 11:09, jehan.procaccia@tem-tsp.eu wrote:<br><br></blockquote></div><blockquote><div dir="ltr">

  

    
  
  
    <p>Hello</p>
    <p>I want to  deny access to a specific SP to users whose ldap
      resolved attribute  contains specific values and allow for other
      values<br>
    </p>
    <p>in my case specific SP is entityID <i><a href="https://sp.im.fr/sp" target="_blank" rel="nofollow noopener noreferrer">https://sp.im.fr/sp</a></i>
      and attribute is <i>eduPersonPrimaryAffiliation</i> which should
      be = to "staff" or "employee" to be allowed access, if a value of
      "student" is resolved (or others as affiliate,member ...) , access
      to the SP should be denied .<br>
    </p>
    <p>So I have created a RelyingPartyOverrides in relaying-party.xml
      with activationCondition based on the value of the attribute for
      that specific relyingParty, the code is loaded (IDP starts well,
      it took me a while with lots of errors ...) , now users can
      connect , but also users with eduPersonPrimaryAffiliation that are
      different from staff or employee  in my case [1] :-( <br>
    </p>
    <p>I guess that my IdP (v5.1.6) does not deny access when my
      relying-party activationCondition evaluates to false, and then it
      might falls back to the default relying-party config with the
      default SAML2 SSO profile which is not restricted !? <br>
    </p>
    <p>can you help me buiding an operational configuration that allow
      access to that specific SP only for users whose  <i>eduPersonPrimaryAffiliation
        = staff or employee </i>? <br>
    </p>
    <p>is relying-party.xml the right place to do that, or
      access-control.xml file should be involved ? <br>
    </p>
    <p>regard</p>
    <p>jehan<br>
    </p>
    <p><i><font size="2"> <util:list id="<b>shibboleth.RelyingPartyOverrides</b>"><br>
        </font></i></p>
    <p><font size="2"><i>                <bean id="MistralAI"
          parent="RelyingPartyByName" <b>c:relyingPartyIds="#{<!-- -->{'<a href="https://sp.im.fr/sp" target="_blank" rel="nofollow noopener noreferrer">https://sp.im.fr/sp</a>'}}"</b>><br>
                            <br>
              <property name="<b>activationCondition</b>"><br>
                  <bean parent="<b>shibboleth.Conditions.SimpleAttribute</b>"><br>
                      <property name="attributeValueMap"><br>
                          <map><br>
                              <entry key="<b>eduPersonPrimaryAffiliation</b>"><br>
                                  <list><br>
                                      <value><b>staff</b></value> </i></font></p>
    <p><font size="2"><i>                           
          <value>employee</value></i></font></p>
    <p><font size="2"><i>                        </list><br>
                              </entry><br>
                          </map><br>
                      </property><br>
                  </bean><br>
          </property> <br>
          <br>
                <property name="profileConfigurations"><br>
                  <list><br>
                      <bean parent="SAML2.SSO"<br>
                            p:encryptAssertions="false"<br>
                            p:checkAddress="false" /><br>
                  </list><br>
              </property><br>
          <br>
          </bean></i><br>
      </font><br>
    </p>
  

-- <br>For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw<br>To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br></div></blockquote></div><br>-- <br>For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw<br>To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net</div></div><div><br></div></div></body></html>