previous X509 auth result contains subject with no public credentials

[Cantor, Scott]

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

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

Yes, that's a fair point. I've never had to do this so I don't fully appreciate the complexities at this point. I think you're correct that even if the merging function itself produces a usable result, that doesn't help because the original results aren't altered by that and they're still a problem.

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

You don't have to remove anything, it's the addition of the UsernamePrincipal that allows the "simple" method to work. The X500Principal won't hurt anything. Flows just silently skip themselves if they can't understand the Subject's contents.

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

Yes, it would, because if you were doing that, c14n would simply not happen again on reuse/SSO. What you're seeing is a result of the MFA usage, it doesn't happen normally that way. That's why it didn't show up with testing. I realized you were using MFA because of that before you actually confirmed it.

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

I think there are multiple ways of enhancing things to address the problem, I would have to study things more to determine the best way to proceed. Adding a function point to customize the results is probably a better general answer, but there's still the fundamental problem of having to serialize things that aren't friendly to handle (though certificates should be doable). Just because something gets added doesn't mean it will actually get serialized. In effect, converting the contents to a UsernamePrincipal up front is essentially a form of c14n since that just forces things to get handled by the "simple" c14n flow, which is in some sense just the no-op case.

But it's fairly important an issue get filed or it will be forgotten, I'm not really working on this problem at the moment and I won't remember to go back and get into it.

-- Scott