Need help with canonicalization and attribute resolver in a mutual auth scenario.

[Johan Åkerstrøm]

Scott,

>>In the SSO tracer I see  no NameID or other attributes.
>Well, that's a matter of NameID generation config and attribute resolver/filter config, as it used to be. Has nothing particularly to do with use of X.509, really, in most cases. The documentation on all that is in the wiki, but I describe some specific cases below.
>> So to my questions….
>> 
>>How do I copy the CN of the subject from the x509 certificate into NameID?
>
>First you need to separate in your mind the issue of what the canonical principal name is after authentication from what ends up in a NameID. They don't have to be related.

OK, Should I think bearer of the token and just look at asserted attributes?

>If you *want* the canonical principal name to be the CN, then you would first configure the c14n/x500 flow to do that work for you by telling it to do that, but I believe that's the default (I think the CN OID is 2.5.4.3, and that's the default attribute it pulls from in c14n/x500-subject-c14n-config.xml. So that should be done for you.

Added debug level logging now and can see that the CN is pulled from the certificate in idp-process .log not sure how that is linked in to an attribute.

==================8<----------------------------------
2015-07-14 21:27:43,842 - DEBUG [net.shibboleth.idp.authn.impl.X509AuthServlet:109] - 1 X.509 Certificate(s) found in request
2015-07-14 21:27:43,842 - DEBUG [net.shibboleth.idp.authn.impl.X509AuthServlet:119] - End-entity X.509 certificate found with subject 'CN=johan, OU=Infra, O=Company, L=Town, ST=Region, C=GB', issued by 'CN=johan, OU=Infra, O=Company, L=Town, ST=Region, C=GB'
2015-07-14 21:27:43,878 - INFO [net.shibboleth.idp.authn.impl.ValidateExternalAuthentication:107] - Profile Action ValidateExternalAuthentication: External authentication succeeded for Subject: [CN=johan, OU=Infra, O=Company, L=Town, ST=Region, C=GB]
2015-07-14 21:27:43,891 - DEBUG [net.shibboleth.idp.authn.AbstractValidationAction:274] - Profile Action ValidateExternalAuthentication: Adding custom Principal(s) defined on underlying flow descriptor
2015-07-14 21:27:43,892 - DEBUG [net.shibboleth.idp.authn.impl.PopulateSubjectCanonicalizationContext:79] - Profile Action PopulateSubjectCanonicalizationContext: Installing 2 canonicalization flows into SubjectCanonicalizationContext
2015-07-14 21:27:43,892 - DEBUG [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:100] - Profile Action SelectSubjectCanonicalizationFlow: Checking canonicalization flow c14n/x500 for applicability...
2015-07-14 21:27:43,892 - DEBUG [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:83] - Profile Action SelectSubjectCanonicalizationFlow: Selecting canonicalization flow c14n/x500
2015-07-14 21:27:43,893 - DEBUG [net.shibboleth.idp.authn.impl.X500SubjectCanonicalization:171] - Profile Action X500SubjectCanonicalization: Searching for RDN to extract from DN: CN=johan,OU=Infra,O=Company,L=Town,ST=Region,C=GB
2015-07-14 21:27:43,910 - DEBUG [net.shibboleth.idp.authn.impl.X500SubjectCanonicalization:178] - Profile Action X500SubjectCanonicalization: Extracted RDN with OID 2.5.4.3: johan
2015-07-14 21:27:43,911 - DEBUG [net.shibboleth.idp.authn.AbstractSubjectCanonicalizationAction:226] - Profile Action X500SubjectCanonicalization: trimming whitespace of input string 'johan'
2015-07-14 21:27:43,912 - DEBUG [net.shibboleth.idp.session.impl.DetectIdentitySwitch:148] - Profile Action DetectIdentitySwitch: No previous session found, nothing to do
2015-07-14 21:27:43,912 - DEBUG [net.shibboleth.idp.authn.impl.FinalizeAuthentication:95] - Profile Action FinalizeAuthentication: Canonical principal name was established as 'johan'
2015-07-14 21:27:43,912 - DEBUG [net.shibboleth.idp.session.impl.UpdateSessionWithAuthenticationResult:221] - Profile Action UpdateSessionWithAuthenticationResult: Creating new session for principal johan
2015-07-14 21:27:43,913 - DEBUG [net.shibboleth.idp.session.impl.StorageBackedSessionManager:502] - Created new session a79fcb1e7a2f5155ec51029fe52ec6f5d65437d69cbdbeda575ceadbb53ef7ec for principal johan
2015-07-14 21:27:43,913 - DEBUG [net.shibboleth.idp.session.impl.StorageBackedIdPSession:556] - Saving AuthenticationResult for flow authn/X509 in session a79fcb1e7a2f5155ec51029fe52ec6f5d65437d69cbdbeda575ceadbb53ef7ec
==================8<----------------------------------

I don't know how to pull the principal from the session into an attribute. 
Hence, I'm simplifying my set up since I am hitting the famous head against the even more famous wall. This is currently all that I have in my attribute-resolver.xml

   <resolver:AttributeDefinition id="affiliation" xsi:type="ad:Simple" sourceAttributeID="affiliation">
        <resolver:Dependency ref="staticAttributes" />
    </resolver:AttributeDefinition>


    <resolver:DataConnector id="staticAttributes" xsi:type="dc:Static">
        <dc:Attribute id="affiliation">
            <dc:Value>member</dc:Value>
        </dc:Attribute>
    </resolver:DataConnector>

Shouldn't this give me an attribute with the name affiliation and the value member in my SAML assertion? 
Feels like I am missing something fundamental here. 

>Getting that into a NameID generally involves creating an attribute definition in the resolver that pulls from the principal name (there's an attribute definition type of Principal for that purpose), and releasing that attribute to the SP. Then you can follow the docs in the NameIDGenerationConfiguration page that describe how to do custom NameID format handling, and there's an example in the saml-nameid.xml file for that.

>Using the NameID is not recommended however.
Got it and will stay away from NameID in that perspective. 


>>How do I use the whole subject (which corresponds to an LDAP distinguished name) from the certificate to lookup other attributes or group memberships in our LDAP directory?

>Somewhat oddly, I don't think the built-in code actually has the option to set the canonical name based on the whole DN, because DNs are pretty awful and people don't use them much. So you would first have to build a scriptlet in the resolver in an attribute definition to pull the DN directly out of the Java Subject. Once that's done, you can plug that in as a dependency into a DataConnector to fill in part of the search filter template.

>If you want to file a RFE to get the DN populated as the canonical principal name, feel free, that seems like an oversight.

Will consider it...