Anwendungsfälle:
Das Problem: Der Login über einen solchen Gast- oder Funktionsaccount darf keinen Zugriff auf andere Service-Provider ermöglichen.
Die Lösung: Der Shibboleth-IdP (ab Version 4.1.x) wird so konfiguriert, dass beim Login über einen Context Check Interceptor die Entity ID des anfragenden Service-Providers und die Nutzerkennung des aktuellen Users gegen eine entsprechende Regel abgeglichen werden. Handelt es sich um einen Gast-/Funktionsaccount, der auf einen „verbotenen“ SP zugreifen will, wird der Anmeldevorgang abgebrochen.
Hierzu muss zunächst das Modul idp.intercept.ContextCheck
aktiviert werden:
(Windows) C:\opt\shibboleth-idp> bin\module.bat -t idp.intercept.ContextCheck || bin\module.bat -e idp.intercept.ContextCheck (Other) $ bin/module.sh -t idp.intercept.ContextCheck || bin/module.sh -e idp.intercept.ContextCheck
Anschließend wird die entsprechende Bedingung formuliert:
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:util="http://www.springframework.org/schema/util" xmlns:p="http://www.springframework.org/schema/p" xmlns:c="http://www.springframework.org/schema/c" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd" default-init-method="initialize" default-destroy-method="destroy"> <bean id="shibboleth.context-check.Condition" parent="shibboleth.Conditions.OR"> <constructor-arg> <list> <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{'https://sp.example.org/shibboleth'}}" /> <bean parent="shibboleth.Conditions.NOT"> <constructor-arg> <bean class="net.shibboleth.idp.profile.logic.SimpleAttributePredicate" p:useUnfilteredAttributes="true"> <property name="attributeValueMap"> <map> <entry key="uid"> <list> <value>shibgast</value> </list> </entry> </map> </property> </bean> </constructor-arg> </bean> </list> </constructor-arg> </bean> <!-- ... --> </beans>
Dabei ist shibgast
die User Id des Gast-/Funktionsaccounts, und https://sp.example.org/shibboleth
die Entity Id des Service Providers, auf den diese Person(en) Zugriff erhalten soll(en). Passen Sie diese Werte sowie den Namen des Quell-Attributs (hier uid
) bitte entsprechend an. Die Bedingung ist erfüllt, wenn
shibgas
angemeldet hat oder
Anders ausgedrückt: Wenn shibgast
sich mit einem anderen SP verbindet, ist die Bedingung nicht erfüllt und der Context Check - und somit auch die Anmeldung - schlagen fehl.
Der Context Ceck muss dann noch zu den Post-Authentication-Flows in relying-party.xml
hinzugefügt werden:
<!-- ... --> <bean parent="SAML2.SSO" p:postAuthenticationFlows="#{ {'terms-of-use', 'context-check', 'attribute-release'} }" /> <!-- ... -->
Anschließend den IdP neu starten.