Page Comparison

A parent bean called shibboleth.TranscodingRule to support direct use of the class, but in most cases (*) it's easier to use the shibboleth.TranscodingProperties parent bean, which allows the rule to be defined using the Spring <props> element. There's a little bit more syntax used in order to support merging of the properties back into a set of defaults we include to reduce the amount of work and duplication needed to define new rules.

(*) The main reason you might need the direct class is to use non-String values of properties, which is not a general need; the system converts things from String internally to simplify things.

The conf/attributes/default-rules.xml file includes a number of examples of this syntax being used.

The other useful bean, also used in that file, is shibboleth.TranscodingRuleLoader, and the value of that bean with this syntax is that it allows multiple rules to be collected together in a list without each individual rule having to be given a Spring bean ID, which is just more work and hassle to assign while avoiding duplication.

The previous example for "mail" when defined in this syntax would be:

<bean parent="shibboleth.TranscodingProperties">
	<property name="properties">
		<props merge="true">
			<prop key="id">mail</prop>
			<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
			<prop key="saml2.name">urn:oid:0.9.2342.19200300.100.1.3</prop>
			<prop key="saml1.name">urn:mace:dir:attribute-def:mail</prop>
		</props>
	</property>
</bean>

The only functional difference is that this rule includes via merge a couple of additional default properties that are included in the IdP's system files.

The alternative syntax for defining a single rule is just to use a Java Properties file (only the non-XML flat-file syntax is supported, because, obviously...)

An example of this was shown earlier. A key point: the name of the file is irrelevant. It doesn't make assumptions about the attribute ID based on the name or allow that property to be omitted. In practice of course it's sensible to name things appropriately for ease of maintenance.

The use of Properties files is also handled by the shibboleth.TranscodingRuleLoader bean, which supports vacuuming up a directory tree of Properties file all at once.

This is illustrated for you in the conf/attribute-registry.xml file, and by default the conf/attributes/custom/ directory is already designated as a place for these files to be created. You can create any subfolders you want for organization because it will walk the whole tree.

You can of course create other loader beans that load different directories if desired.

Also discussed above, there are several beans defined to support the creation of the mapping rules contained in the registry.