shib-storedid2computedid-example/conf/c14n/subject-c14n.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:c="http://www.springframework.org/schema/c"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                           http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"
                           
       default-init-method="initialize"
       default-destroy-method="destroy">
    
    <!-- ========================= Java Subject -> Principal Mapping ========================= -->

    <!--
    These are lists of Subject Canonicalization flows that turn complex Subject data into a string-based
    principal name that the rest of the IdP can operate on. They're used primarily after authentication
    and also during less common operations like SAML attribute queries, to map the SAML Subject into a
    principal name.
    
    Flows are identified with an ID that corresponds to a Spring Web Flow subflow name.
    
    Most of the simple settings that configure these flows are in subject-c14n.properties.
    -->

    <!--
    ====================================================================
    Flows used after authentication to produce canonical principal name.
    ====================================================================
    -->
    <util:list id="shibboleth.PostLoginSubjectCanonicalizationFlows">
        <!--
        This is an advanced post-login step that performs attribute resolution and then produces a username
        from an attribute value. To enable universally, just uncomment, but if you want it to run under more
        specific conditions, set an activationCondition property to a condition to apply. 
        -->
        <!-- <bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" /> -->

        <!--
        This is an advanced option for use with SAML 2 proxy authentication to a second IdP that
        derives the principal name semi-directly from the incoming NameID value. It is functionally
        akin to the c14n/SAML2Transform flow for SAML Request scenarios, but separately defined so
        a suitably restrictive format list and/or condition can be applied to it. 
        -->
        <!-- <ref bean="c14n/SAML2ProxyTransform" /> -->

        <!--
        This is an alternative that handles Subjects containing an X500Principal object and
        allows extraction from the DN.
        -->
        <ref bean="c14n/x500" />

        <!--
        This is the standard post-login step that returns a username derived from the login process. If you
        have more complex needs such as mapping a certificate DN into a principal name, an alternative may
        be required such as that above, but you can use this for simple transforms.
        -->
        <ref bean="c14n/simple" />
    </util:list>
    
    <!-- What SAML NameID formats do you want to support direct transformations for while proxying? -->
    <util:list id="shibboleth.ProxyNameTransformFormats">
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</value>
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</value>
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</value>
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName</value>
        <value>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</value>
    </util:list>
    
    <!--
    Under what conditions should direct NameID mapping during proxying be allowed? By default, never.
    Any condition can be used here; the example is suitable for enumerating a number of IdPs to allow.
    -->
    <bean id="shibboleth.ProxyNameTransformPredicate" parent="shibboleth.Conditions.ProxyAuthentication">
        <constructor-arg name="collection">
            <list>
                <!-- <value>https://idp-proxy.example.org</value> -->
            </list>
        </constructor-arg>
    </bean>
    
    <!--
    Regular expression transforms to apply to incoming proxied subject names. The default empty list just
    echoes the name through unmodified.
    -->
    <util:list id="shibboleth.ProxyNameTransforms">
        <!--
        <bean parent="shibboleth.Pair" p:first="^(.+)@example\.org$" p:second="$1" />
        -->
    </util:list>
    
    
    <!--
    =======================================================================
    Flows used during SAML requests to reverse-map NameIdentifiers/NameIDs.
    Below the list are some settings that might be useful to adjust.
    =======================================================================
    -->
    <util:list id="shibboleth.SAMLSubjectCanonicalizationFlows">

        <!-- The next four are for handling transient IDs (in-storage and stateless variants). -->
        <ref bean="c14n/SAML2Transient" />
        <ref bean="c14n/SAML2CryptoTransient" />
        <ref bean="c14n/SAML1Transient" /> 
        <ref bean="c14n/SAML1CryptoTransient" /> 
        
        <!-- Handle a SAML 2 persistent ID, provided a stored strategy is in use. -->
        <!-- <ref bean="c14n/SAML2Persistent" /> -->
        
        <!--
        Finally we have beans for decoding arbitrary SAML formats directly. By default, these are turned off,
        having *no* circumstances for which they apply (see shibboleth.TransformNamePredicate below).
        -->
        <ref bean="c14n/SAML2Transform" />
        <ref bean="c14n/SAML1Transform" />
    </util:list>
    
    <!-- What SAML NameID formats do you want to support direct transformations for? -->
    <util:list id="shibboleth.NameTransformFormats">
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</value>
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</value>
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</value>
        <value>urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName</value>
        <value>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</value>
    </util:list>

    <!--
    Under what conditions should direct NameID mapping be allowed? By default, never.
    Any condition can be used here; the example is suitable for enumerating a number of SPs to allow.
    -->
    <bean id="shibboleth.NameTransformPredicate" parent="shibboleth.Conditions.RelyingPartyId">
        <constructor-arg name="candidates">
            <list>
                <!-- <value>https://sp.example.org</value> -->
            </list>
        </constructor-arg>
    </bean>
    
    <!--
    Regular expression transforms to apply to incoming subject names. The default empty list just
    echoes the name through unmodified.
    -->
    <util:list id="shibboleth.NameTransforms">
        <!--
        <bean parent="shibboleth.Pair" p:first="^(.+)@example\.org$" p:second="$1" />
        -->
    </util:list>
    
</beans>