IDP proxing for vendors non-DS/Wayf capabilities

[Jehan PROCACCIA]

I read through the Doc: https://wiki.shibboleth.net/confluence/display/IDP4/SAMLAuthnConfiguration
to resume Subject Canonicalization sub chapter of that doc:
 "there is a requirement to process the AuthenticationResult into a normalized principal name,...this isn't a trivial thing to do. there is no simple "username" to rely on and the system requires some dedicated configuration to know what to do."
So I followed the doc by defining in attribute-resolver.xml the mail attribute as beeing of type="SubjectDerivedAttribute":

<AttributeDefinition id="canonicalName" xsi:type="SubjectDerivedAttribute"
    forCanonicalization="true" principalAttributeName="mail" />

then select mail from my upstreamIDP issuer in attribute-filter.xml 

<PolicyRequirementRule xsi:type="Issuer" value="https://upstreamIDP.domain.fr/idp/shibboleth" />
                <AttributeRule attributeID="mail" permitAny="true" />

and , then (I missed that one step in my previous tests, it was not mentioned in KB ...) , enabling post-Login c14n flow in subject-c14n.xml : <bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" />

Finaly associate the id=canonicalName for "the list of attributes to resolve for normalizing the subject" in attribute-sourced-subject-c14n-config.xml

<util:list id="shibboleth.c14n.attribute.AttributesToResolve">
        <value>canonicalName</value>
    </util:list>

<util:list id="shibboleth.c14n.attribute.AttributeSourceIds">
        <value>canonicalName</value>
    </util:list>

Now the canonicalization process does include the c14n/attribute flow, see logs below with 3 canonicalization flows (there were the 2 defaults before; c14n/x500 and c14n/simple) 

2021-02-03 22:41:08,282 -- DEBUG [net.shibboleth.idp.authn.impl.PopulateSubjectCanonicalizationContext:75] - Profile Action PopulateSubjectCanonicalizationContext: Installing 3 canonicalization flows into SubjectCanonicalizationContext

although there is a local (IDPproxy) ldap connector with (as exepected) no mail value: 

2021-02-03 22:41:08,372 -- DEBUG [net.shibboleth.idp.attribute.resolver.dc.ldap.TemplatedExecutableSearchFilterBuilder:214] - Template text (mail=$resolutionContext.principal) yields (mail=$resolutionContext.principal)
2021-02-03 22:41:08,394 -- DEBUG [net.shibboleth.idp.attribute.resolver.AbstractResolverPlugin:258] - Resolver plugin 'myLDAP' produced no value.

Then I can see that the mail attribute seems well passThrough upstreamIDP to IDPproxy by my "canonicalName" attribute definition:

2021-02-03 22:41:08,397 -- DEBUG [net.shibboleth.idp.attribute.resolver.ad.impl.ContextDerivedAttributeDefinition:179] - SubjectDerivedAttributeDefinition canonicalName Generated 1 values
2021-02-03 22:41:08,398 -- DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:139] - Attribute Definition 'canonicalName': produced an attribute with the following values [StringAttributeValue{value=jehan.procaccia at imtbs-tsp.eu}]
2021-02-03 22:41:08,400 -- DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:519] - Attribute Resolver 'ShibbolethAttributeResolver': Attribute 'canonicalName' has 1 values after post-processing


Until now everything seems righ, but then, next log line,  it fails : 

2021-02-03 22:41:08,408 -- ERROR [net.shibboleth.idp.authn:-2] - Uncaught runtime exception
java.lang.NullPointerException: null
	at net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl.collectExportingDataConnectors(AttributeResolverImpl.java:542)
2021-02-03 22:41:08,413 -- INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:142] - Profile Action SelectAuthenticationFlow: Moving incomplete flow authn/SAML to intermediate set
2021-02-03 22:41:08,413 -- DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:274] - Profile Action SelectAuthenticationFlow: No specific Principals requested
2021-02-03 22:41:08,413 -- DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:312] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow
2021-02-03 22:41:08,413 -- INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:316] - Profile Action SelectAuthenticationFlow: No potential flows left to choose from, authentication failed


Am I failing somewhere in my Subject canonicalization ? or I hit something wrong ? (I use IDP 4.0.1 ) 

Thanks .

----- Mail original -----
De: "Cantor, Scott" <cantor.2 at osu.edu>
À: "users" <users at shibboleth.net>
Envoyé: Mercredi 3 Février 2021 15:37:14
Objet: Re: IDP proxing for vendors non-DS/Wayf capabilities

On 2/3/21, 9:22 AM, "users on behalf of Jehan PROCACCIA" <users-bounces at shibboleth.net on behalf of jehan.procaccia at tem-tsp.eu> wrote:

>  Thanks Nate, I'am getting closer to an operational solution ! 
>    from the basic workflow describe in the doc: 

As I keep having to note, that is not the documentation. You should not use anything in the KB section in isolation but only after reading and following the actual documentation, which in this case is in the SAMLAuthnConfiguration topic.

And, yes, subject c14n is covered.

-- Scott


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