how to deny acces to a SP based on attribute value

[Jehan PROCACCIA]

Hello 

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 . 
Indeed , I am not convince that replying-party config could be the right way to do that ? 

I am surprise though that this kind of access control to a Service Provider based on an attribute value is not that much documented 
I've seen it in [ https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509766/ActivationConditions | https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509766/ActivationConditions ] 
chapter => Attribute Checking 
but it's not clear where to apply it, and how to corrolate that to a specific SP for denied access 
If there a simple way to do that " deny acces to a SP based on attribute value" ? , I take it in the first place 

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 ! 

Thanks for you help . 

jehan 




De: "db--- via users" <users at shibboleth.net> 
À: "Shib Users" <users at shibboleth.net> 
Cc: "db at alaska.edu" <dabantz at alaska.edu>, "users" <users at shibboleth.net> 
Envoyé: Dimanche 7 Décembre 2025 21:38:40 
Objet: Re: how to deny acces to a SP based on attribute value 

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. 
David.Bantz @Alaska.edu 




On Dec 7, 2025, at 11:09, jehan.procaccia at tem-tsp.eu wrote: 





BQ_BEGIN



Hello 

I want to deny access to a specific SP to users whose ldap resolved attribute contains specific values and allow for other values 


in my case specific SP is entityID [ https://sp.im.fr/sp | https://sp.im.fr/sp ] and attribute is eduPersonPrimaryAffiliation 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 . 


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] :-( 


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


can you help me buiding an operational configuration that allow access to that specific SP only for users whose eduPersonPrimaryAffiliation = staff or employee ? 


is relying-party.xml the right place to do that, or access-control.xml file should be involved ? 


regard 

jehan 


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


<bean id="MistralAI" parent="RelyingPartyByName" c:relyingPartyIds="#{ {' [ https://sp.im.fr/sp | https://sp.im.fr/sp ] '}}" > 

<property name=" activationCondition "> 
<bean parent=" shibboleth.Conditions.SimpleAttribute "> 
<property name="attributeValueMap"> 
<map> 
<entry key=" eduPersonPrimaryAffiliation "> 
<list> 
<value> staff </value> 

<value>employee</value> 

</list> 
</entry> 
</map> 
</property> 
</bean> 
</property> 

<property name="profileConfigurations"> 
<list> 
<bean parent="SAML2.SSO" 
p:encryptAssertions="false" 
p:checkAddress="false" /> 
</list> 
</property> 

</bean> 

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

BQ_END


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20251208/e7fc88b2/attachment.htm>