The document raises but leaves unanswered several questions and issues related to the "branding bounces" that will happen in the proposed implementation. I agree that these will be an issue and that consistency across all XSEDE sites that support SSO will be critical.
The example screenshots in the document highlighted but did not resolve the branding question, and before implementation begins, there should be more explicit thought and specific guidance provided to developers. In addition, the branding on the pages that XSEDE will control should be reviewed and considered holistically from both user-confusion and XSEDE branding perspectives.
Other minor details should perhaps be addressed:
Is "weblogin.xsede.org" the right URL? Should that be "auth.xsede.org" (analogous to Globus), "shibboleth.xsede.org" (emulating Illinois example), or "sso.xsede.org" reflecting that this is XSEDE Single Sign-on (SSO).
Also, the design effort should consider the design/info presented on the weblogin.xsede.org page (second figure on p.7). Notably, the page refers explicitly to "Science Gateways" twice, but not once to supporting "Single Sign-on". Similarly, should "Create New Account" be an option on the SSO page? Aesthetically, the page also seems more cluttered and dated in its design than, say, the Globus pages.
Agreed. First, I agree that the question of "to skin or not to skin" needs to be thought through carefully. (See related issues raised by Kate and Maytal.) Bear in mind that brand bouncing can't be completely eliminated. We can minimize it, but not eliminate it. We can skin all of the Globus pages, but not the identity provider login pages (wherever each user decides to actually enter his/her userid/password). Those could be campus servers, a Google page, a non-XSEDE Globus page, a DOE lab, ORCID, NIH, who knows? (It could even be an XSEDE page, in which case it would be consistent!) OAuth requires IDPs to provide their own login pages and there's nothing we can do about that--it's on purpose as a part of the design of OAuth. Another twist: CILogon displays a screen the first time a user authenticates to most campuses, so to avoid a branding bounce there, we'd need to work with the CILogon project to skin their interface as well. I believe it's supported, but I don't know the terms offhand. (Jim Basney knows, of course.)
Second, it does seem to me that this might be a good time to revise the XSEDE skin used in Globus, since the XSEDE website and portal have been refreshed and the Globus skin has fallen behind. I wonder if there's anything we could do to ensure that future design changes are kept in sync? I understand it's not a central issue for the XSEDE web/portal team, but maybe there's something easy we could do just to remind ourselves that somebody should look at it?
Hi Dave and Lee,
As pointed out by Lee, there's implicit "brand bouncing" between at least 2 brands (RP and the authentication server) in OIDC and I believe most users understand this considering how pervasive it has become (in terms of signing into a website to offer comments using their Facebook/google account). IMHO, it's better to educate the few confused users on this aspect rather than offering a classically Phishy page (regardless of any fancy naming). It has always been tremendously unsettling to me whenever I saw a "skin".
I say "classically Phishy" because:
"Phishing is typically carried out by email spoofing[4] or instant messaging,[5] and it often directs users to enter personal information at a fake website, the look and feel of which are identical to the legitimate one and the only difference is the URL of the website in concern."
https://en.wikipedia.org/wiki/Phishing
Although the user is not asked for credentials in the case of skins, there's no escaping the fact that the "skin" looks Phishy being that it masquerades as being something that can't be verified by the user that it legitimately is (regardless of any agreement between XSEDE and Globus for such portrayal).
If we totally want to restrict brand bounces to 2 (RP and IdP), wherein Globus and CILogon aren't seen by the user, then the correct way to do it is by using Frames and such (instead of user-agent redirections), which is how Duo Security implements 2-factor.
In the absence of such an implementation, I strongly feel it would suffice for the redirecting page to let the user know about the target page and for the target page (globus in this case) to simply mention the RP (as the referred-from party). Users shouldn't be disturbed by this because they aren't being asked for their credentials here, and are only being asked to select an IdP.
I will get back on the other questions raised by Dave, after discussing them with Jim.
Thanks,
venkat