====== Activation Conditions ======
<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:**\\
Bedingungen an Hand derer man verschiedene Aktionen und Abläufe am IdP beeinflussen bzw. steuern kann.

**Beispiele für Anwendungsszenarien:**\\
  * Vermeidung unnötiger LDAP-Abfragen / Einschränkung Attribute-Resolver\\
  * Freigabe von Attributen an bestimmte Verlässlichkeitsklassen / Föderationen\\
  * Filterung von Attributen je nach SP

In das Installationsverzeichnis wechseln.\\
Neue Config-File samt Conditions anlegen.

<file xml conf/activation-conditions.xml>
<!-- ... -->
	<bean id="SP-consumes-persistentId" parent="shibboleth.Conditions.RelyingPartyId">
		<constructor-arg name="candidates">
			<list>
				<value>https://your.sp.de/shibboleth</value>
				<value>https://testsp2.aai.dfn.de/shibboleth</value>
			</list>
		</constructor-arg>
	</bean>

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

	# Die Angabe einer ActivationCondition führt hier leider nicht dazu, dass die LDAP-Abfragen nur gestellt werden, wenn der SP in der Condition steht
	# Sondern:
	#	- Das Attribut wird nämlich erst gebaut (LDAP-Abfrage) und erst danach greift die Condition und regelt die Weitergabe des Attributs an die Filter
	#	- Die Condition MUSS daher auch an die groupLDAP-Dependency (DataConnector) gehangen werden, um die Ausführung der LDAP-Anfragen zu steuern
	#
	<bean id="SP-consumes-isMemberOf" parent="shibboleth.Conditions.RelyingPartyId">
		<constructor-arg name="candidates">
			<list>
				<value>https://your.other.sp.de/shibboleth</value>
			</list>
		</constructor-arg>
	</bean>
<!-- ... -->
</file>

Config-File überall einbinden, wo Conditions genutzt werden sollen.

<file xml conf/services.xml>
<!-- ... -->
	<util:list id="shibboleth.RelyingPartyResolverResources">
		...
		<value>%{idp.home}/conf/activation-conditions.xml</value>
	</util:list>

	<util:list id ="shibboleth.AttributeResolverResources">
		...
		<value>%{idp.home}/conf/activation-conditions.xml</value>
	</util:list>
<!-- ... -->
</file>

Aktivierung der Conditions.

<file xml conf/relying-party.xml>
<!-- ... -->
	<util:list id="shibboleth.RelyingPartyOverrides">
		<bean parent="RelyingParty" p:activationCondition-ref="SP-consumes-persistentId">
			<property name="profileConfigurations">
				<list>
					<bean parent="SAML2.SSO" p:postAuthenticationFlows="attribute-release" p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'}}" />
					<ref bean="SAML2.Logout" />
					<ref bean="SAML2.AttributeQuery" />
					<ref bean="SAML2.ArtifactResolution" />
				</list>
			</property>
		</bean>
	</util:list>
<!-- ... -->
</file>

<file xml conf/attribute-resolver.xml>
<!-- ... -->
	<AttributeDefinition xsi:type="Simple" id="isMemberOf" activationConditionRef="SP-is-in-DFNAAI-Basic">
		<InputDataConnector ref="groupLDAP" attributeNames="cn" />
		<DisplayName xml:lang="de">Gruppe</DisplayName>
		<DisplayName xml:lang="en">Group</DisplayName>
		<DisplayDescription xml:lang="de">Name der Gruppe zu der der Nutzer gehört</DisplayDescription>
		<DisplayDescription xml:lang="en">Name of group with which the person is associated</DisplayDescription>
		<AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:isMemberOf" />
		<AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" friendlyName="isMemberOf" />
	</AttributeDefinition>

	<AttributeDefinition xsi:type="Simple" id="isMemberOf" activationConditionRef="SP-consumes-isMemberOf">
		<InputDataConnector ref="groupLDAP" attributeNames="cn"/>
		<DisplayName xml:lang="de">Gruppe</DisplayName>
		<DisplayName xml:lang="en">Group</DisplayName>
		<DisplayDescription xml:lang="de">Name der Gruppe zu der der Nutzer gehört</DisplayDescription>
		<DisplayDescription xml:lang="en">Name of group with which the person is associated</DisplayDescription>
		<AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:isMemberOf" />
		<AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" friendlyName="isMemberOf" />
	</AttributeDefinition>

	# Gruppen werden so definiert, dass Sie ein oder mehrere Entitlements erhalten, die Aussage darüber geben an welchen SP diese gerichtet sind
	#
	# student, groups, tu-dresden.de
	#	dn: cn=student,ou=groups,dc=tu-dresden,dc=de
	#	objectClass: top
	#	objectClass: posixGroup
	#	objectClass: eduPerson
	#	cn: student
	#	gidNumber: 345
	#	memberUid: stud
	#	eduPersonEntitlement: https://your.other.sp.de/shibboleth
	#
	# Bei dem beschriebenen Vorgehen werden nur die Gruppen aus LDAP heraus gesucht, in denen der Nutzer Mitglied ist und die für den SP bestimmt sind
	# Damit ist sichergestellt, dass nicht alle SPs alle Gruppen erhalten
	# Dabei soll zusätzlich gewährleistet sein, dass LDAP nur dann nach Gruppen gefragt wird, wenn der SP diese auch wirklich freigegeben bekommen hat
	# Somit werden unnötige LDAP-Abfragen bei allen Logins an anderen SPs vermieden
	#
	<DataConnector id="groupLDAP" xsi:type="LDAPDirectory" activationConditionRef="SP-consumes-isMemberOf"
		ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
		baseDN="%{idp.attribute.resolver.LDAP.groupsDN}"
		principal="%{idp.attribute.resolver.LDAP.bindDN}"
		principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
		searchScope="ONELEVEL"
		maxResultSize="0">
		<FilterTemplate>
			<![CDATA[
				(&(eduPersonEntitlement=$resolutionContext.attributeRecipientID)(memberUid=$resolutionContext.principal))
			]]>
		</FilterTemplate>
	</DataConnector>
<!-- ... -->
</file>

Wenn conf/activation-conditions.xml noch nicht existiert hat, muss der Tomcat neugestartet werden, damit die services.xml neu eingelesen wird.\\
Ansonsten genügt es bei Erweiterung um neue Conditions den jeweiligen Service neu zu laden.

**Links / Dokumentation:**\\
https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions\\
https://wiki.shibboleth.net/confluence/display/IDP30/ExternalAttributePluginActivationConditions\\
https://wiki.shibboleth.net/confluence/display/IDP30/RegistrationAuthorityConfiguration\\
https://wiki.shibboleth.net/confluence/display/IDP30/InEntityGroupConfiguration\\
https://wiki.shibboleth.net/confluence/display/IDP30/ReloadableServices

{{tag>archiv fixme}}