shibboleth.c14n.attribute.PrincipalNameLookupStrategy bean

[Cantor, Scott]

On 2/15/17, 7:12 PM, "users on behalf of Andrew Morgan" <users-bounces at shibboleth.net on behalf of morgan at orst.edu> wrote:

> The documentation for Attribute-based Canonicalization [1] teases us with 
> "This will become significantly simpler to use in a future release (via 
> the shibboleth.c14n.attribute.PrincipalNameLookupStrategy bean)..."

Oops, needs to be updated. I'll redo it and park the legacy examples.

> Since I upgraded to v3.3 recently, I'm re-visiting the c14n configuration. 
> Is there some shiny new way to handle c14n now?  My users can login with 
> either their uid or eppn.  I followed the existing documentation at [1]
>  with a scripted attribute to do this.  If there is a simpler way, that
>  would be great!

I don't know if I'd say it's shiny, it's just less cluttered and confusing than having to do that weird check inside the resolver, which is really depending on a lot of internals to know what it's doing. Actually now that I'm reading the original example (which we got from Mike I think), I actually don't understand it, or perhaps it's actually wrong, so yeah, I'd say go with mine.

My Duo set up relies on this to normalize down about 4 different inputs down to name.# with the LDAP lookup, and my bean inside the attribute-sourced-c14n-whatever file is (my scripts use Rhino, so beware):

   <bean id="shibboleth.c14n.attribute.PrincipalNameLookupStrategy"
            class="net.shibboleth.idp.profile.context.navigate.ScriptedContextLookupFunction"
            factory-method="inlineScript">
        <constructor-arg>
            <value>rhino-nonjdk</value>
        </constructor-arg>
        <constructor-arg>
            <value>
            <![CDATA[
            importPackage(Packages.net.shibboleth.idp.authn.principal);
            importPackage(Packages.net.shibboleth.idp.authn.context);
            var principalName = null;
            var subject = profileContext.getSubcontext(SubjectCanonicalizationContext).getSubject();
            var princs = subject.getPrincipals(UsernamePrincipal);
            if (princs.size() == 1) {
                principalName = princs.iterator().next().getName();
            }
            principalName;
            ]]>
            </value>
        </constructor-arg>
    </bean>

I would say that's a bit less cluttered, and certainly the resolver config is simpler without it. 

I can redo the example with that approach.

-- Scott