...
A secondary feature in V4.1+ allows for a Java Subject that contains one or more IdPAttributePrincipal objects to be processed directly for an IdPAttribute to pull the value from. This is primarily of use with various "external" authentication options such as SAML proxying, allowing a SAML Attribute decoded from another IdP to be directly consumed and used as a canonical principal name without the hassle of the attribute resolution process (and configuration). This feature can be leveraged by adjusting various properties (see the reference below) to disable use of the Attribute Resolver and reference the Java Subject directly (note this is not referring to the SAML <Subject> element but to the Java object created as a result of all successful authentication flows in the IdP).
General Configuration
| Expand | ||
|---|---|---|
| ||
Use conf/c14n/attribute-sourced-subject-c14n-config.xml to configure this flow, along with the AttributeResolverConfiguration. Typically you will supply a list of attributes to resolve and a list of attributes to search for in the results. The first such attribute with a suitable value will supply the username to return. By default, the only transform applied to the result is a trim of leading or trailing whitespace. Case-folding and regular expression replacements can be added, per the reference section below. |
| Expand | ||
|---|---|---|
| ||
Use conf/c14n/subject-c14n.properties to configure this flow, along with the AttributeResolverConfiguration. If your system is upgraded, you may continue to use conf/c14n/attribute-sourced-subject-c14n-config.xml as before, or you may remove it, while ensuring the new properties are being loaded. There are two ways this flow can locate a suitable IdPAttribute to use:
These methods can be combined, in the sense that the list of attributes to search for may be found in either way, so it's possible to run the resolver conditionally and/or check both the Subject and the resolution results. In most cases this is an either/or situation and the resolver won't be used if you expect the data to be in the Subject already. When pulling directly, you will typically just supply a list of attributes to check for (first value wins), and set the idp.c14n.attribute.resolutionCondition property to "shibboleth.Conditions.FALSE", to turn off the full attribute resolution step. When using the resolver, typically you will supply a list of attributes to resolve and a list of attributes to search for in the results. The first such attribute with a suitable value will supply the username to return. By default, the only transform applied to the result is a trim of leading or trailing whitespace. Case-folding and regular expression replacements can be added, per the reference section below. The regular expression replacement feature is the only one remaining that still requires XML and you may define that bean, if needed, in conf/c14n/subject-c14n.xml |
...