How to send attributes when using MFA
ntakei at sios.com
Wed Apr 3 08:56:23 EDT 2019
I modified subject-c14n.xml as you told me and solved this problem.
Thanks for your advice.
On Thu, Mar 28, 2019 at 22:23 Cantor, Scott <cantor.2 at osu.edu> wrote:
> 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
> 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
> 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
> For Consortium Member technical support, see
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users