The only service that uses weblogin.xsede.org is Globus Auth. Services that use Globus Auth will not need to change when Globus Auth migrates its XSEDE provider from weblogin.xsede.org to idp.xsede.org.
With this transition XSEDE's web SSO flow will now require multi-factor authentication using Duo. This is a significant user facing change and security improvement. The design document covers this change in detail, however, I'm concerned that optional reviewers may not have read this technically dense (and excellent) document to note this change, and that perhaps others should at least be given a heads up.
How about a brief e-mail explaining that with this transition XSEDE will start requiring multi-factor for all web SSO logins that we send to the optional reviewers who did not sign-off (Maytal, Alex), others (Victor, Greg), and maybe to the operators of XSEDE web services integrated with web SSO? If we can estimate that the transition will happen after a specific date, say after April 1st, we should mention that so that these folks know to reply with concerns before then.
Technically I don't see any issues with this transition, and I'm sure that Alex and Derek don't either from an Operations security perspective, I just want to make sure we communicate ahead of time to those that will likely care and notice so they aren't surprised when it happens.
Section E.2.3. Availability or volatility of resources
(Apologies if this is covered elsewhere) - How will this service meet the requirements for availability expressed in section E.2.3.? Where are the backup services to be deployed and what resources will be expected to keep them ready for use should accessibility to the primary service instance be lost?
I'm glad you asked, because I think the text in section E.2.3 was not correct. With the use of AWS for idp.xsede.org (XCI-757) and cilogon.org (XCI-783), I think the old text about "Tier 1 Critical Production" services with "next day parts" and "hot spare at another location" is obsolete. I've revised Section E.2.3 in xci-339-design-v1.3.pdf to contain the following instead:
CILogon is operated by NCSA in a University of Illinois AWS account using 3 AWS availability zones. CILogon also uses redundant Hardware Security Modules at NCSA for certificate signing.
The XSEDE IdP is operated in XSEDE's AWS account by XSEDE SysOps personnel.
What steps do each of the applications that currently employ weblogin.xsede.org need to port or re-implement to use idp.xsede.org instead?
The only service that uses weblogin.xsede.org is Globus Auth. Services that use Globus Auth will not need to change when Globus Auth migrates its XSEDE provider from weblogin.xsede.org to idp.xsede.org.
With this transition XSEDE's web SSO flow will now require multi-factor authentication using Duo. This is a significant user facing change and security improvement. The design document covers this change in detail, however, I'm concerned that optional reviewers may not have read this technically dense (and excellent) document to note this change, and that perhaps others should at least be given a heads up.
How about a brief e-mail explaining that with this transition XSEDE will start requiring multi-factor for all web SSO logins that we send to the optional reviewers who did not sign-off (Maytal, Alex), others (Victor, Greg), and maybe to the operators of XSEDE web services integrated with web SSO? If we can estimate that the transition will happen after a specific date, say after April 1st, we should mention that so that these folks know to reply with concerns before then.
Technically I don't see any issues with this transition, and I'm sure that Alex and Derek don't either from an Operations security perspective, I just want to make sure we communicate ahead of time to those that will likely care and notice so they aren't surprised when it happens.
Thanks,
JP
Agreed. I added our draft email to Section G of xci-339-design-v1.3.pdf.
Thanks,
Jim
Thanks. Fixed in xci-339-design-v1.3.pdf. -Jim
I'm glad you asked, because I think the text in section E.2.3 was not correct. With the use of AWS for idp.xsede.org (XCI-757) and cilogon.org (XCI-783), I think the old text about "Tier 1 Critical Production" services with "next day parts" and "hot spare at another location" is obsolete. I've revised Section E.2.3 in xci-339-design-v1.3.pdf to contain the following instead:
CILogon is operated by NCSA in a University of Illinois AWS account using 3 AWS availability zones. CILogon also uses redundant Hardware Security Modules at NCSA for certificate signing.
The XSEDE IdP is operated in XSEDE's AWS account by XSEDE SysOps personnel.
Thanks,
Jim