SubjectDerivedAttributeDefinition Generated no values

[Wessel, Keith]

Thanks, Steve. It is, in fact, the attribute filter piece that was needed. I'll try and add that to the instructions on the wiki if the editor will cooperate for me.

Scott, if I understand correctly, the attribute filter config piece is needed regardless of if I used a subject derived attribute definition or a subject data connector, is that correct? So, the only advantage to the data connector route is it would let me bulk map attributes coming in from the proxy?

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Mak, Steve
Sent: Tuesday, October 13, 2020 11:39 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: SubjectDerivedAttributeDefinition Generated no values

Here's what I have working in our sandbox:

conf/attributes/custom/proxy-employeeNumber.properties (I had to define this because the proxy isn't using the SAML2 default format or name)

    id=proxy-employeeNumber
    transcoder=SAML2StringTranscoder
    saml2.name=employeeNumber
    saml2.nameFormat=urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified

attribute-resolver.xml:

    <AttributeDefinition id="proxied-subject" xsi:type="SubjectDerivedAttribute" forCanonicalization="true" principalAttributeName="proxy-employeeNumber"/>

attribute-filter.xml:

    <AttributeFilterPolicy id="proxy_idp-test">
        <PolicyRequirementRule xsi:type="Issuer" value="PROXY_IDP_EID"/>
        <AttributeRule attributeID="proxy-employeeNumber" permitAny="true"/>
        <AttributeRule attributeID="foo" permitAny="true"/>
        <AttributeRule attributeID="bar" permitAny="true"/>
        <AttributeRule attributeID="blah" permitAny="true"/>
        <AttributeRule attributeID="blah1" permitAny="true"/>
        <AttributeRule attributeID="blah2" permitAny="true"/>
    </AttributeFilterPolicy>

c14n/subject-c14n.xml:

    <util:list id="shibboleth.PostLoginSubjectCanonicalizationFlows">
        <!--
        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 configure simple transforms in simple-subject-c14n-config.xml
        -->
        <ref bean="c14n/simple" />
        <!--
        This is an advanced post-login step that performs attribute resolution and then produces a username
        from an attribute value. Most of this configuration is handled by attribute-sourced-c14n-config.xml.
        To enable universally, just uncomment, but if you want it to run under more specific conditions,
        set an activationCondition property to a condition function to use to control when it should run. 
        -->
        <bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow"/>
        <!--
        This is an alternative that handles Subjects containing an X500Principal object and
        allows extraction from the DN.
        <ref bean="c14n/x500" />
        -->
    </util:list>

c14n/attribute-sourced-subject-c14n-config.xml:

    <util:list id="shibboleth.c14n.attribute.AttributesToResolve">
        <value>proxied-subject</value>
    </util:list>

    <util:list id="shibboleth.c14n.attribute.AttributeSourceIds">
        <value>proxied-subject</value>
    </util:list>

- Steve

-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net