previous X509 auth result contains subject with no public credentials

[Cantor, Scott]

On 11/20/20, 7:08 PM, "Bobby Lawrence" <robertl at jlab.org> wrote:

>    So I guess I should have mentioned that I am actually using the MFA flow with X509 auth as a second factor.  I actually it
> set up so that the password flow runs first, then a script determines if the user needs a second factor and if so, I transition
> to a custom flow where the user can select what second factor they want to use (OTP or certificate/smart card).

Certificates are not really historically a "second factor". That doesn't really have anything to do with it, I just thought it was interesting.

>  When they make their choice, the MFA flow runs that selection last.  It may be that my problem is that c14n/x500 runs
> first and sets the principal name instead of letting the c14n/simple flow fetch the UsernamePrincipal from the other
> authentication result?  I might try putting the c14n/simple first in the list...

They all run until one succeeds, that only impacts the order they're tried.

As I said, this case applies because re-running the factors from within an MFA rule reuses the embedded results that have already been serialized and so are missing the information that's documented to be missing when that happens.

>    It might be nice if the different contexts (c14n for example) could be re-used, but I'm pretty sure only the
> authentication results are persisted in the session...am I right?

Yes. Contexts are a per-request concept, they never get serialized.

>    Anyway - aside from my suggestions or somehow re-creating the entire X509 authn as a custom flow, are you saying
> that I'm kinda stuck?  

No, I'm saying you need a custom merging function. The MFA documentation covers the signature of the function, you have to build you own final result. If you're already digging into the code you can probably find the default function it uses as an example.

-- Scott