how to deny acces to a SP based on attribute value
jehan.procaccia at tem-tsp.eu
jehan.procaccia at tem-tsp.eu
Mon Dec 8 18:51:02 UTC 2025
ok, forget my question about "/if entry key="sp_entity_id_1" should be
replaced with the real EntityIDs concerned/" (in message below which
wasn't post to the list because of a wrong sender email address which is
not subscribed to the list ...)
of course ... I did it, /<*entry
key="*//https://cool-mist/self-service/methods/saml/organizations/orgid//*"*>/
and now access control works as expected
/2025-12-08 18:50:05,221 - 157.157.2.2 - INFO [Shibboleth-Audit.SSO:333]
-
157.157.2.2|2025-12-08T17:49:59.876564883Z,2025-12-08T17:49:57.375970590Z|2025-12-08T17:50:05.221062518Z|//first.last at im.fr//|//https://cool-mist/self-service/methods/saml/organizations/orgid//|||||||*false|true||Redirect*||*ContextCheckDenied*|||19b908c49d7ec7cb925700ad266e0cf9f008ee292dbf9bcc79fb0c2e20072576|Mozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/140.0.0.0 Safari/537.36/
Thanks.
jehan/
/
On 08/12/2025 18:45, jehan Procaccia wrote:
>
> Thanks for that confirmation to use ContextCheckInterceptConfiguration
> <https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509927/ContextCheckInterceptConfiguration>
>
> I tried to use you example of config, everything went right for a user
> connection, except that the user has attribute = staff and I wanted in
> that sample usecase only attribute = student , so the user was allowed
> access and not denied as expected :-( (idp logs bellow [1]
>
> I wonder if I have well interpreted your sample config , I
> particularly wonder if entry /key="sp_entity_id_1"/ should be replaced
> with the real EntityIDs concerned ?
>
> Here is what I took/change from your sample,
>
> 1) relying-party.xml with my SP entityID as a Overrides :
>
> / <bean id="MistralAI" parent="RelyingPartyByName"
> c:relyingPartyIds="#{{'https://cool-mist/self-service/methods/saml/organizations/orgid'}}">/
>
> / <property name="profileConfigurations">
> <list>
> <bean parent="SAML2.SSO"
> p:encryptAssertions="false"
> *p:postAuthenticationFlows="#{{'context-check'}}"*
> p:checkAddress="false" /> </list></property></bean>/
>
> 2) Then in /conf/intercept/context-check-intercept-config.xml
> /
>
> /<bean *id="OnlyMistralAI"
> *parent="shibboleth.Conditions.SimpleAttribute"
> p:useUnfilteredAttributes="true">
> <property name="attributeValueMap">
> <map>
> <entry key=*"eduPersonPrimaryAffiliation"*>
> <list>
> <value>*student*</value>
> </list> </entry> </map> </property></bean>/
>
> /<!-- Map associating each SP entity id to its access condition. -->
> <util:map id="ConditionMap">
> <*entry key="sp_entity_id_1"*>
> <ref bean="OnlyAdmin"/>
> </entry>
> <*entry key="sp_entity_id_2"*> => shoudl it contain the real
> EntityID ? here
> //https://cool-mist/self-service/methods/saml/organizations/orgid/
> / <ref bean="OnlyMistralAI"/>
> </entry>
> </util:map>/
>
> the final part
>
> /<!-- Bean checking the access condition for each SP entity id -->
> <bean id="shibboleth.context-check.Function"
> parent="shibboleth.ContextFunctions.Scripted"
> factory-method="inlineScript"
> c:outputType="java.lang.String"
> p:customObject-ref="ConditionMap"> ..../
>
> was taken as it, without any change from yours .
>
> Thanks for you help .
>
> Regards
>
> jehan
>
> [1] IDP logs while /first.last at im.fr does connetcto SP alhtougth he as
> staff attribute vs student which was expeted in that config , note
> also that this IDP is functionning a an proxy IDP so that I can
> benefit from ou Discovery Service for our internal Federation, Vendor
> SP here works only with a bilateral IDP, so attributes are
> passingThrough, perhaps a missleading message below ?
> /
>
> /2025-12-08 18:18:30,803 - 157.157.2.2 - WARN
> [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:596]
> - Attribute Resolver 'ShibbolethAttributeResolver': *could not export
> attibute 'eduPersonPrimaryAffiliation' from data connector
> 'passthroughAttributes' since an attribute of that name already exists.*
> 2025-12-08 18:18:30,806 - 157.157.2.2 - WARN
> [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:596]
> - Attribute Resolver 'ShibbolethAttributeResolver': could not export
> attibute 'eduPersonAffiliation' from data connector
> 'passthroughAttributes' since an attribute of that name already exists.*
> */
>
> /2025-12-08T17:18:32.070774542Z|first.last at im.fr|https://cool-mist/self-service/methods/saml/organizations/orgid|_c769e04b0a02a02569f8babf4beca95a|password|2025-12-08T17:02:07.580Z|uid,eduPersonPrimaryAffiliation,mail,eduPersonAffiliation,givenName,schacHomeOrganization,eduPersonPrincipalName,sn|first.last@im.fr|emailAddress|false|true||Redirect|POST||Success||19b908c49d7ec7cb925700ad266e0cf9f008ee292dbf9bcc79fb0c2e20074360|Mozilla/5.0
> (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
> Chrome/140.0.0.0 Safari/537.36/
>
> /
>
> /
>
> On 08/12/2025 11:12, Gianluca Amato via users wrote:
>
>> I think the correct approach is to use a context-check interceptor
>> (https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509927/ContextCheckInterceptConfiguration).
>>
>> You need to first install the support with:
>> bin/module.sh -e idp.intercept.ContextCheck
>> Then, you need to modify |conf/relying-party.xml |enabling the
>> post-authentication flow.
>> <bean parent="SAML2.SSO"
>> p:postAuthenticationFlows="#{{'context-check'}}"
>> p:encryptAssertions="false" />
>> Finally, create a file
>> /conf/intercept/context-check-intercept-config.xml /with the
>> configuration. We use something liek the following:
>> <!-- Bean for restricting access to the admin user. -->
>> <bean id="OnlyAdmin" parent="shibboleth.Conditions.SimpleAttribute"
>> p:useUnfilteredAttributes="true">
>> <property name="attributeValueMap">
>> <map>
>> <entry key="uid">
>> <list>
>> <value>admin_uid</value>
>> </list>
>> </entry>
>> </map>
>> </property>
>> </bean>
>>
>> <!-- Bean for restricting access to people with member affiliation. -->
>> <bean id="OnlyMembers" parent="shibboleth.Conditions.SimpleAttribute" p:useUnfilteredAttributes="true">
>> <property name="attributeValueMap">
>> <map>
>> <entry key="eduPersonAffiliation">
>> <list>
>> <value>member</value>
>> </list>
>> </entry>
>> </map>
>> </property>
>> </bean>
>>
>> <!-- Map associating each SP entity id to its access condition. -->
>> <util:map id="ConditionMap">
>> <entry key="sp_entity_id_1">
>> <ref bean="OnlyAdmin"/>
>> </entry>
>> <entry key="sp_entity_id_2">
>> <ref bean="OnlyMembers"/>
>> </entry>
>> </util:map>
>>
>>
>> <!-- Bean checking the access condition for each SP entity id -->
>> <bean id="shibboleth.context-check.Function"
>> parent="shibboleth.ContextFunctions.Scripted"
>> factory-method="inlineScript"
>> c:outputType="java.lang.String" p:customObject-ref="ConditionMap">
>> <constructor-arg>
>> <value>
>> <![CDATA[
>> var event = "proceed";
>> var rpid = input.getSubcontext(
>> "net.shibboleth.profile.context.RelyingPartyContext").getRelyingPartyId();
>> var condition = custom.get(rpid);
>> if (condition != null && !condition.test(input)) {
>> event = "ContextCheckDenied";
>> }
>> event;
>> ]]>
>> </value>
>> </constructor-arg>
>> </bean>
>>
>> Best regards,
>> --gianluca
>>
>> On Sun, Dec 7, 2025 at 7:15 PM jehan.procaccia at tem-tsp.eu
>> <jehan.procaccia at tem-tsp.eu> wrote:
>>
>> 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/ 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'}}"*>
>>
>> <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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20251208/464e8423/attachment.htm>
More information about the users
mailing list