...
By default, the system operates essentially like as before by attempting each method defined in the legacy list (shibboleth.PostLoginSubjectCanonicalizationFlows) in conf/c14n/subject-c14n.xml. For existing deployments, this is assumed to be “working already” and so is backward-compatible through any upgrades to this or later versions.
However, it is not recommended in most cases to continue to leverage this list bean to reference or define c14n methods (with the exception of the need to support older/existing plugins, discussed later).
Internally, the following beans are defined with default configurations of the supported c14n methods:
...
...
...
...
...
Most of these methods are predominantly expected to be configured by means of method-specific properties in conf/c14n/subject-c14n.properties, as discussed on those pages. In a few cases, there are still additional Spring beans used, as noted on each of their documentation pages.
To Instead, to use one or more of these c14n methods with a particular login flow, you define a property specific to that login flow in conf/authn/authn.properties (they are present but commented in the latest “shipping” default version of that file). These properties contain a comma-delimited list of c14n bean IDs to attempt for each login flow.
...
In this manner, each login method can be explicitly configured to run the c14n logic required without any concern about overlap.
Internally, the following beans are defined with default configurations of the supported c14n methods:
Most of these methods are predominantly expected to be configured by means of method-specific properties in conf/c14n/subject-c14n.properties, as discussed on those pages. In a few cases, there are still additional Spring beans used, as noted on each of their documentation pages.
Older Plugins
With IdP plugins targeted at V5.0 and V5.1, the property based approach described above is not supported yet, and so you will need to refer to the older documentation and leverage the legacy list bean to configure c14n. When in doubt, refer to the plugin’s documentation on that.
Advanced Topics
Multiple Instances of a Method
It is now possible to configure multiple copies of a particular c14n method with different settings. This requires additional Spring XML configuration since the default instances get most of their behavior from a single set of properties. The attribute-sourced method is the most common use case for this, since its configuration includes the specification of which attribute(s) to resolve and source from, and that method also doubles as a means of extracting a username from incoming data when proxying to another IdP.
For example, consider the use case of the Password login flow relying on a local directory to remap the username via the Attribute Resolver, while simultaneously using the SAML proxy login flow to extract an Attribute decoded from the incoming assertion. While it is possible to do this (at times) with a single instance of the attribute-sourced c14n method, a more reliable way to prevent accidental overlap is to define a second instance of the method.
Assuming the properties used to configure this method are set up to support the Password/Attribute Resolver use case, a second instance can be added with a bean such as the following added to conf/c14n/subject-c14n.xml:
| Code Block | ||
|---|---|---|
| ||
<bean id="c14n/proxy-sourced" parent="c14n/attribute-sourced"
p:attributesToResolve="proxyUsername"
p:attributeSourceIds="proxyUsername"
p:resolveFromSubject="true"
p:resolutionCondition="false" /> |
While the beans noted above and shown in this example are named with the “c14n/” prefix for both compatibility and clarity, that isn’t a requirement, so deployers are free to define new instances of these methods using whatever naming they prefer, but the prefix is a convenient aid/reference later.