====== Custom Login Flow & Context Check Interceptor ======

<callout color="#ff9900" title="Archiv">
Dieser Artikel ist ein Community-Beitrag für Shibboleth IdP 3.x. Es ist unklar, ob er für Shibboleth IdP 4.x so noch gilt.
</callout>

**Was ist das:**\\
Unter den Begriffen versteht man Modelle, mit deren Hilfe man das Nutzererfahren beim Login an individuelle Vorgaben anpassen kann.\\
Dabei kann der Ablauf durch beliebige Schritte und Prüfungen erweitert werden.\\
Analog ist dies z.B. mit den Terms-Of-Use oder dem Attribute-Release gleichzusetzen.\\
Der Gestaltung sind hierbei keine Grenzen gesetzt, da man auf alle Informationen zugreifen kann, die innerhalb des normalen Login-Vorgangs vorhanden sind.

**Beispiele für Anwendungsszenarien:**\\
  * Ausschluss von Funktionsaccounts, so dass sich diese NICHT an Diensten der DFN-AAI anmelden können
  * Zugriffssteuerung für bestimmte Serviceprovider, die keine ausreichenden Authorisierungsmechanismen bieten oder die die dafür nötigen Attribute erst garnicht erhalten sollen
  * Ausschluss von bestimmten Nutzergruppen von bestimmten Diensten (SPs)
  * Generelle Definition von Abbruchbedigungen für den Loginvorgang

In das Installationsverzeichnis wechseln.\\
Neue Config-File samt Conditions anlegen wie im Abschnitt [[de:shibidp:config-activation-condition|Activation Conditions]] beschrieben.

<file xml conf/activation-conditions.xml>
<!-- ... -->
	<bean id="user-is-functional" class="net.shibboleth.idp.profile.logic.SimpleAttributePredicate" p:useUnfilteredAttributes="true">
		<property name="attributeValueMap">
			<map>
				<entry key="groupmemberOf">
					<list>
						<value>cn=idmgrp-functions-org-10000000,ou=groups,dc=yourdomain,dc=de</value>
					</list>
				</entry>
			</map>
		</property>
	</bean>

	<bean id="SP-is-in-DFNAAI" parent="shibboleth.Conditions.EntityDescriptor">
		<constructor-arg name="pred">
			<bean class="org.opensaml.saml.common.profile.logic.RegistrationAuthorityPredicate"
				<constructor-arg>
					<list>
						<value>https://www.aai.dfn.de</value>
					</list>
				</constructor-arg>
			</bean>
		</constructor-arg>
	</bean>

	<bean id="SP-allow-functional-user" parent="shibboleth.Conditions.RelyingPartyId">
		<constructor-arg name="candidates">
			<list>
				<value>https://your.sp.de/shibboleth</value>
			</list>
		</constructor-arg>
	</bean>

	<bean id="login-proceed" parent="shibboleth.Conditions.OR">
		<constructor-arg>
			<list>
				<bean parent="shibboleth.Conditions.NOT">
					<constructor-arg>
						<list>
							<ref bean="user-is-functional" />
						</list>
					</constructor-arg>
				</bean>
				<bean parent="shibboleth.Conditions.NOT">
					<constructor-arg>
						<list>
							<ref bean="SP-is-in-DFNAAI" />
						</list>
					</constructor-arg>
				</bean>
				<ref bean="SP-allow-functional-user" />
			</list>
		</constructor-arg>
	</bean>
<!-- ... -->
</file>

Den Standard Check-Interceptor kopieren und an die eingenen Bedürfnisse anpassen.

<code>
# mkdir -p flows/intercept/functional-user-check
# cp system/flows/intercept/context-check-flow.xml flows/intercept/functional-user-check/functional-user-check-flow.xml
# cp system/flows/intercept/context-check-beans.xml flows/intercept/functional-user-check/functional-user-check-beans.xml
</code>

Neuen Interceptor-Flow definieren.

<file xml flows/intercept/functional-user-check/functional-user-check-flow.xml>
<!--...-->
	<bean-import resource="functional-user-check-beans.xml" />
<!--...-->
</file>

Datei mit den nötigen Conditions verlinken.

<file xml flows/intercept/functional-user-check/functional-user-check-beans.xml>
<!--...-->
	<import resource="../../../conf/activation-conditions.xml" />
	<alias name="login-proceed" alias="ContextCheckPredicate"/>
<!--...-->
</file>

Interceptor-Flow bekannt machen.

<file xml conf/intercept/profile-intercept.xml>
<!--...-->
	<bean id="intercept/functional-user-check" parent="shibboleth.InterceptFlow"/>
<!--...-->
</file>

Abbruch-Event überschreiben, falls eigene Fehlermeldungen ausgegeben werden möchten.

<file xml flows/intercept/functional-user-check/functional-user-check-flow.xml>
<!--...-->
	then="proceed" else="FunctionalUserCheckDenied" />
<!--...-->
</file>

Abbruch-Event definieren und mit gewünschten Error-Messages verlinken.

<file xml conf/intercept/intercept-events-flow.xml>
<!--...-->
	<end-state id="FunctionalUserCheckDenied" />
	<global-transitions>
		<transition on="FunctionalUserCheckDenied" to="FunctionalUserCheckDenied" />
	</global-transitions>
<!--...-->
</file>

Event als lokales Event definieren, so dass der Login-Vorgang abgebrochen wird und der Nutzer am IdP verweilt, statt eine Antwort an den SP zu senden.

<file xml conf/errors.xml>
<!--...-->
	<util:map id="shibboleth.LocalEventMap">
		<entry key="FunctionalUserCheckDenied" value="true" />
<!--...-->
</file>

Zu verwendende Fehlermeldungen definieren.

<file properties messages/error-messages_de.properties (error-messages.properties)>
<!--...-->
	FunctionalUserCheckDenied                       = functional
	functional.title                                = Zugang verweigert
	functional.message                              = Funktionsaccounts sind für diesen Dienst nicht zul\u00E4ssig.
<!--...-->
</file>

Neuen Interceptor-Flow für die gewünschten Relying-Parties aktivieren.

<file xml conf/relying-party.xml>
<!--...-->
	<bean parent="SAML2.SSO" p:postAuthenticationFlows="#{{'functional-user-check', 'attribute-release'}}"
<!--...-->
</file>

**Links / Dokumentation:**\\
  * https://wiki.shibboleth.net/confluence/display/IDP30/Authentication
  * https://wiki.shibboleth.net/confluence/display/IDP30/ProfileInterceptConfiguration
  * https://wiki.shibboleth.net/confluence/display/IDP30/ContextCheckInterceptConfiguration
  * https://wiki.shibboleth.net/confluence/display/IDP30/RegistrationAuthorityConfiguration
  * https://wiki.shibboleth.net/confluence/display/IDP30/InEntityGroupConfiguration
  * https://wiki.shibboleth.net/confluence/display/IDP30/ErrorHandlingConfiguration

{{tag>archiv}}