How to send attributes when using MFA

[Cantor, Scott]

On 3/27/19, 11:40 PM, "users on behalf of Noriyuki TAKEI" <users-bounces at shibboleth.net on behalf of ntakei at sios.com> wrote:

> Do you have any solutions?

This comes down to how MFA results from different flows get merged, and how the mechanism called subject canonicalization works after each login flow to produce a normalized principal name. It's actually doing this so you notice the disconnect and act to resolve it in the "right" way for your system.

The default MFA merging function, which you can substitute, does a straight "merge" of all the Principal objects in the Java Subjects produced by each login flow, and builds a final Subject that's a union of all of them. In this case, there will be an X500Principal and a simpler UsernamePrincipal, coming from the two flows separately.

After X.509 and External run, they each would perform their own c14n step, and the default c14n flows that are configured include "simple" and "x500". Each of those would, independently, work successfully on the two login flows in question, but "x500" is listed ahead of "simple" in the list of supported flows in subject-c14n.xml, which dictates the order they're tried.

Since x500 is first, it gets a chance to look at the merged result from MFA, and since it sees an X500Principal in the Subject, it activates and it produces the X.500-derived value as the result, and that's the final value used.

If you want the username from the External login to be used, you could probably achieve that by swapping the flow order in the list of beans so that "simple" runs first.

The real problem here is the risk you take by them being different. How do you know that these two principal names are really the same person? MFA between two independent factors is very complex to orchestrate and is usually only safe when there's a clear input/output process between the identity of one factor and the way the other factor gets processed.

-- Scott