Section C and XSEDE User Portal

2 posts / 0 new
Last post
Section C and XSEDE User Portal

Section C states that this design will allow XSEDE to retire

The XSEDE User Portal currently uses a 2-legged OAuth login flow (aka "username/password") provided by

  • 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 for those, so this design will not allow 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 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 As you wrote in a Jira comment on 06/18/2020, "The 2-legged OAuth interface is indeed provided by and not by I'm still following one loose end to make certain 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.


Log in to post comments