c14n attribute sourced subject, multiple principals

[Joseph Fischetti]

> I would not use the IPAddress flow. Its function is to map address ranges
to
> generally artificial or at least service-account usernames. I doubt that's
what
> you're really after here.

Make sense.  That's what I thought in reading the documentation, but I was
going to investigate anyway.

> Using a condition bean from the MFA script to do the detection would be
the
> right way to do it (if you don't want to use Duo's features for it).

A condition bean as in... activation condition?  Or a condition within the
custom script that does a lookup, etc?


> In practice, it's very possible you really want Duo to do it. Using the
IdP to do
> it is primarily in order to NOT assert MFA as the resulting context class
in the
> event of a bypass, since it knows the Duo step didn't run. Most people
doing
> bypasses are intending to lie to the SP and claim MFA was actually done,
and
> the IdP can, but does not particularly make it easy, to do that.

I wanted to avoid bouncing the user through the Duo page (if all Duo is
going to do is let them through anyway).  Does it matter?  Probably not.
But I don't like the idea of depending on an outside service anyway.  I
guess you're suggesting I do it because it's the "right thing to do" not
necessarily because it's the best way to do it.

Re: my other point... I added a log to the PrincipalNameLookupStrategy, and
that final run through it (when the princs = 2), I have my eppn (which I
would expect), and the value that I entered when I logged in [1].  Weird.
The first time it runs, it's username (because that's what I entered, and it
needs to be that for the resolver?).  The second time it runs, it's my eppn
(which it should be, because that's what I told it to use), and the third
time it runs it has both (which didn't happen before I added the
authn/IPAddress flow).

------------------------------------------------
[1]
2020-03-18 17:11:46,223 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:3] -
Running c14 subject name canonicalization
2020-03-18 17:11:46,284 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:9] -
princs.size = 1
2020-03-18 17:11:46,293 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:13]
- Principal name found:  MYUSERNAME
2020-03-18 17:11:46,827 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:3] -
Running c14 subject name canonicalization
2020-03-18 17:11:46,829 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:9] -
princs.size = 1
2020-03-18 17:11:46,831 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:13]
- Principal name found:  LEFTofEPPN at marist.edu
2020-03-18 17:11:48,190 - DEBUG [net.shibboleth.idp.checkSecondFactor:37] -
Running Duo Flow
2020-03-18 17:11:58,673 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:3] -
Running c14 subject name canonicalization
2020-03-18 17:11:58,674 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:9] -
princs.size = 2
2020-03-18 17:11:58,678 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:20]
- Principal in context:  LEFTofEPPN at marist.edu
2020-03-18 17:11:58,679 - DEBUG [net.shibboleth.idp.c14nPrincipalScript:20]
- Principal in context:  MYUSERNAME
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5561 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20200318/e9c731fe/attachment.p7s>