Page Comparison

...

Dealing with Conflicting Requirements

Ideally, you You should try and avoid scenarios at all costs a scenario in which you must generate a different kind of data with the same Format for two different SPs. In other words, a given Format should contain the same data regardless of the SP involved. This makes it possible to maintain a simple configuration of any number of generators as above, because the Format chosen will drive the approach used.

If you must deviate from that rule, you can accomodate that by attaching an activationCondition property to a generator bean that triggers based on a particular relying party. In that fashion, you can include multiple generators for a given Format, but limit their use to specific SPs. Since the generators run in order, any generators activated for specific SPs should always come before a generic one for the same Format.

Again, this is a terrible idea and should never be used without first pushing back against such a requirement, as it’s a blatant misuse of the standard and creates significant technical debt for a deployer and whoever inherits such a configuration in the future. Just say no.

<util:list id="shibboleth.SAML2NameIDGenerators">
	<ref bean="shibboleth.SAML2TransientGenerator" />

	<!-- Generates email format for one SP.... -->
	<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
		p:omitQualifiers="true"
		p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
		p:attributeSourceIds="special-mail">

		<property name="activationCondition">
			<bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="https://sp.example.com/shibboleth" />
		</property>
	</bean>

	<!-- Generators email format for all others -->
	<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
		p:omitQualifiers="true"
		p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
		p:attributeSourceIds="mail">
	</bean>

</util:list>

...