How to send attributes when using MFA

[Noriyuki TAKEI]

Hi,Scott.

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
> 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
>
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190403/f01ad920/attachment.html>