Versions Compared

Old Version 31

changes.mady.by.user Scott Cantor

Saved on

compared with

New Version 32

changes.mady.by.user Scott Cantor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In the former case, the result can be pulled directly from the upstream IdP or actually come from the AttributeResolverConfiguration, so there's a lot of flexibility in what to return, but simple passthrough or transform of a SAML Attribute are easy to express. An example below demonstrates this approach for both V4.0 and newer releases (where the configuration to do this was simplified quite a bit).

Using a NameID is strongly discouraged for lots of reasons, not least because it's quite complex to support, but the SAML2ProxyTransform topic discusses how to configure that support.

Note that a common use case is likely to be importing an opaque identifier such as one of the new Subject ID Attributes. While it's possible to directly expose such a value as the principal name, it is probably the case that a lot of mature proxy deployments would be expected to store and map that value to something of their own. That is not exactly a built-in feature at this point, but the most viable path to such a feature at present is probably to leverage a custom post-authentication interceptor that might detect an unlinked value and provide the user interface necessary to establish and store the linking information so that subsequent logins can retrieve the mapping from a typical directory or data source. Such an approach is beyond the scope of the documentation at this point.

Attribute-Sourced C14N Example

Note

Note that this example assumes that the only use of this c14n feature is for this proxying use case. If you have a more complex scenario in which there are local authentication methods used as well and you use this feature for those, it gets more complex to combine them without breaking things, so take that into consideration.

Let's say you have an IdP supplying a standard eduPersonPrincipalName SAML Attribute to you and you want to build the principal name directly from that.

...

Localtabgroup
Localtab live
titleV4.0

Now you You will need to add the following to your AttributeResolverConfiguration:

Addition to attribute-resolver.xml
Code Block
languagexml
    <AttributeDefinition id="canonicalName" xsi:type="SubjectDerivedAttribute"
        forCanonicalization="true"
        principalAttributeName="eduPersonPrincipalName" />

The id there is arbitrary, it just delineates the result as a particular piece of data sourced from the proxied IdP and to be used to establish the normalized name. The forCanonicalization flag designates that the source of this is the intermediate result undergoing c14n and never data that is normally floating around the system after authentication.

Once you have that, you must then configure the attribute post-login c14n flow in the typical manner by pointing it at "canonicalName" as its source:

conf/c14n/subject-c14n.xml
Code Block
languagexml
        <!-- Remove comment tags to enable Attribute-based c14n -->
        <bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" />
conf/c14n/attribute-sourced-subject-c14n-config.xml
Code Block
languagexml
    <!--
    A list of attributes to resolve for normalizing the subject. For example, you might
    intend to lookup a name in a directory based on what the user entered. You can make this
    an empty list if you just want to resolve everything you normally would.
    -->
    <util:list id="shibboleth.c14n.attribute.AttributesToResolve">
        <value>canonicalName</value>
    </util:list>

    <!--
    A list of attributes to search for a value to produce as the normalized subject name.
    This will normally be something you resolve above.
    -->
    <util:list id="shibboleth.c14n.attribute.AttributeSourceIds">
        <value>canonicalName</value>
    </util:list>
Localtab live
titleV4.1+

With newer versions, all you have to do is to configure the attribute post-login c14n flow via properties by pointing it at "eduPersonPrincipalName" as a source. The properties to enable this are commented out in conf/c14n/subject-c14n.properties and are noted below.

conf/c14n/subject-c14n.xml
Code Block
languagexml
        <!-- Remove comment tags to enable Attribute-based c14n -->
        <bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" />
conf/c14n/subject-c14n.properties
Code Block
idp.c14n.attribute.attributeSourceIds = eduPersonPrincipalName
# Allows direct use of attributes via SAML proxy authn, bypasses resolver
idp.c14n.attribute.resolveFromSubject = true
idp.c14n.attribute.resolutionCondition = shibboleth.Conditions.FALSE

...