Section C states that this design will allow XSEDE to retire weblogin.xsede.org.
The XSEDE User Portal currently uses a 2-legged OAuth login flow (aka "username/password") provided by weblogin.xsede.org.
- Does CILogon provide a 2-legged service that XUP could use? (I think the answer is no?)
- Is there a plan to change XUP from using 2-legged OAuth to using 3-legged OAuth? (I think the answer is no?)
If XUP needs 2-legged OAuth logins and CILogon doesn't provide them, that means XUP will need to continue using weblogin.xsede.org for those, so this design will not allow weblogin.xsede.org to be retired. Is that right?
If this is the case, it raises another design issue. Specifically, can Globus Auth handle XSEDE identities being asserted both by the 2-legged weblogin.xsede.org and the 3-legged CILogon? I suspect the answer is "yes" because the 2-legged login flow doesn't result in an EPPN or EPTID that could conflict with the new EPPN & EPTID returned by CILogin, which is how Globus keeps track of identities from CILogon IDPs. Still, it's probably a scenario that should be reviewed with the Globus team to make sure it will work, and if there's anything that needs to be changed or configured in Globus Auth to make sure it works, we'll need that to be done.
I don't think it's correct to say that the XUP uses weblogin.xsede.org. As you wrote in a Jira comment on 06/18/2020, "The 2-legged OAuth interface is indeed provided by auth.globus.org and not by weblogin.xsede.org. I'm still following one loose end to make certain weblogin.xsede.org plays no part in it, but at this point I think it's safe to assume it doesn't." Thus, I wrote the design doc with the understanding that any interaction between the XUP and Globus Auth was out-of-scope for this activity.
-Jim