previous X509 auth result contains subject with no public credentials

[Bobby Lawrence]

Ok - I've got a custom merging strategy implemented but to make it work, I had to do something I didn't quite expect.  Originally this custom merge function simply replaced any X500Principal in the merged Subject with a UsernamePrincipal containing the subject alternative name fetched from the certificate found in the public credentials.  However just doing this on the merged result didn't change anything after the first authn.  The second time through, I still had the same problem. 

I think the issue is the fact that a function in net.shibboleth.idp.authn.impl.PopulateMultiFactorAuthenticationContext (DefaultResultLookupStrategy) fetches only the AuthenticationResultPrincipal(s) from the subject and uses those to populate the MFA context with active results.  Its from those active results that the new MFA authentication result is finalized.  So even though my custom merging function replaces the X500Principal in the subject, it still existed in the AuthenticationResultPrincipal and during re-use, everything from the serialized AuthenticationResult subject is effectively discarded except for the AuthenticationResultPrincipal(s)....only the principals from the Subject are serialized (no credentials) and out of those principals, only the AuthenticationResultPrincipal is re-used.
To make it work, I had to remove the X500Principal and add my UsernamePrincipal on the X509 AuthenticationResult subject directly....before all its principals are added to the new 'merged' subject created by net.shibboleth.idp.authn.impl.FinalizeMultiFactorAuthentication. 

So again - this works but while doing this I realized that this only works because I'm using the MFA flow.  If I was using the X509 flow directly without all the MFA pre- and post- processing, this wouldn't work.  It would be nice if there was a way to have some type of finer control of the AuthenticationResult created by each authn flow.  Perhaps a function that could be injected into the flow processing that would be executed in net.shibboleth.idp.authn.AbstractValidationAction in its "buildAuthenticationResult" method after the subject for that flow is populated but before an authentication result is created with that subject.  Scott - maybe this is what you were referring to when you mentioned creating an RFE?  For some reason I don't think so because you mentioned the c14n flow in that comment, but that all happens after the authn flow completes...
 
Anyway - thanks again for your invaluable help Scott

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Monday, November 23, 2020 11:34 AM
To: Shib Users <users at shibboleth.net>
Subject: [EXTERNAL] Re: previous X509 auth result contains subject with no public credentials

On 11/23/20, 11:15 AM, "users on behalf of Bobby Lawrence" <users-bounces at shibboleth.net on behalf of robertl at jlab.org> wrote:

>    I've seen the merging function and I will look into creating a 
> custom one as I've seen if the password flow is skipped (I have x509 
> available as an 'extended' password flow option), then I'm in the same 
> boat....the UsernamePrincipal doesn't exist so the X500Principal is the only one that can be used for subject canonicalization and after the first auth, there is no certificate in the subject to fetch the alternative names from.

Right. If Password was used, the merged Subject will include the simple-compatible Principal but if it's not used, and X.509 gets reused, you'll get a Subject without anything in it to base the c14n on.

-- Scott


--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bg&m=_A8_C6SgnBpuKqyDWemh6A8b82-i-X2dyGVWs2L28Jk&s=eSYGto8tBOIsiM_iu0ddqZiDaiXBm8BrWv8W0geLM4k&e=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net