shibboleth.c14n.attribute.PrincipalNameLookupStrategy bean

[Andrew Morgan]

On Thu, 16 Feb 2017, Cantor, Scott wrote:

> 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.

The existing example *does* work.  I've been using it since last year. 
Uhh, I don't understand how it works though.

Using myself as an example, I can login as "morgan" or 
"morgan at oregonstate.edu" (any case).  In the audit log, it does resolve to 
"morgan" (lowercase).


I don't understand your code example either, though.  How does it know the 
correct output value (username)?  Where is it getting it from?

Thanks,
 	Andy