Sections E.2.2, E.2.5, and E.2.8 all seem to be saying that XSEDE shouldn't allow any other form of authentication in the XSEDE system (at least for non-admins) other than Web SSO. This seems to exceed the authority of this document. This is a design for XSEDE's Web SSO service, NOT a design for all of XSEDE security mechanisms. This isn't the place to prohibit other kinds of authentication.
Another way to put this... This doc is supposed to say what is necessary for Web SSO to work. Prohibiting other kinds of authentication isn't necessary for Web SSO to work. The prohibition might be a fine idea, but the Web SSO design doc is exactly the wrong place to have it, because it's not where someone thinking about another kind of authentication would be looking. That would have to be a broader document, like the XSEDE system-wide security guidelines or something...
It would be fair so say something along the lines of, "XSEDE's Web SSO can only provide a true single sign-on experience if Web applications use a common mechanism. We strongly encourage any XSEDE-related Web service or application to use the Web SSO design described here, in order to maximize the benefit of the Web SSO experience." In fact, I would strongly recommend that we make this point.
Hi Lee,
I wanted to clarify that the wording in the doc does limit the requirement only to "web" services. Non-web services are NOT referred to.
Jim Basney and I felt that providing multiple ways to login to web services could be confusing to the end user and hence the requirement. JP and Kate also recently got rid of individual login fields from confluence, in favor of SSO. Perhaps they can chime in with their thoughts, but whatever is decided by the reviewers, I will modify the doc accordingly.
Thanks,
venkat
We've had many users confused when presented with multiple login options on the same screen. My current thoughts on how to combine user facing simplicity with flexibility and fault tolerance have evolved to this:
Hi JP,
I have discussed your below suggestion with Jim, and my recollection is that he felt it would be too complicated:
"If Globus Auth fails in way that the authenticating client can't recover it should log the error and redirect the user to an alternate login page that uses 2-legged, kerberos, local login, or whatever makes sense. The alternate login page could even support multiple options. I would recommend that at least one of the alternate login options not rely on Globus so that we aren't ever locked out if a single service fails."
We do note under Availability in the design doc:
"If Globus Auth is unavailable, then XSEDE Web SSO will not be available. Globus Auth is hosted in Amazon Web Services (AWS) in a high-availability configuration, so downtime is rare (i.e., only for major AWS outages or rare Globus Auth maintenance downtimes)."
Thanks,
venkat
Right, I think we want to avoid any design requirements that require custom code in the application (e.g., alternate login flows) rather than simply configuring the application's existing OIDC support for Globus/XSEDE Login. We don't want to lose the value of building on the OIDC standard that is widely supported by applications out-of-the-box. My recollection is that when XSEDE adopted Globus Auth, we considered whether to recommend additional auth options/providers and decided to go with a single provider (for simplicity), agreeing that Globus Auth met our availability requirements.
-Jim
Venkat and JP: I didn't explain my concern clearly, and your responses don't address it.
My point is that the Web SSO design doc says in several places that all XSEDE Web applications must use this Web SSO mechanism. That's a policy statement. I don't believe that this document is the place for a policy statement unless the policy has been made via the appropriate XSEDE policy processes.
It would be reasonable to say instead: "All XSEDE Web applications that need to provide a single sign-on experience should use this Web SSO mechanism and not another."
Also note that in Section E.2.6, the statement is not limited to Web applications. In Sections E.2.2 and E.2.8 the statement is limited to Web applications, but it's still stating a policy inappropriately.
If there is a standing XSEDE policy to this effect already, then my concern is irrelevant. Otherwise, I think there are three ways to address the concern:
1) Add the qualifier above, "XSEDE Web applications that need to provide a single sign-on experience..."
2) Remove the statements from this doc.
3) Initiate an official policy-making process and note in the design doc that this is happening. In that case, the policy should be listed as one of the deliverables.
Hi Lee,
CAN-6 says "Rather than manually authenticating against each service before use, it is desirable to authenticate once and use some proof of authentication for subsequent interactions with the same or other services. This approach is sometimes known as single sign-on. "
http://hdl.handle.net/2142/88830
Then a survey of all XSEDE web services was done and documented in the CDP for CAN-6, wherein we identified all the services and specified "it is proposed that these services be modified to implement Web SSO using Globus Auth, via a new button"
So, being that this is a "proposal" or push for ALL XSEDE web services, the requirement in question *implicitly* applies to *only* those that choose to implement XSEDE web SSO. In fact, it could be argued that the wording "that need to" is also going into policy area.
In the new revision I am working on, I have qualified the requirement with the wording "Once SSO is implemented by an XSEDE web service" as in "Once SSO is implemented by an XSEDE web service, end users must NOT be provided with a way to login to XSEDE web services directly, outside of Globus Auth, by the XSEDE web service.".
I hope this addresses your concerns.
Thanks,
venkat
Yes, the changes you made in the new version of the design doc seem 100% appropriate to me. Thanks!