A few things:
1. For some reason the PDF shows as every other page is blank, it makes the document hard to read.
2. I am a little confused about the user guide, is that intended for administrators interested in learning how to use Web SSO or for users who want to know more about it? If it is the latter than it belongs in the user portal. If it is the former, it may go on the web site instead just for clarification on location.
3. Is there going to be a registry or mailing list for 'clients' using XSEDE's web single sign on? This makes communicating with them as a group easier if there are any issues. Is it helpful to know who is using web SSO from the XSEDE standpoint for reporting, etc.
4. The button on page 4 with the text on it. That takes up a significant amount of space on a web page. Is that going to be just a suggested design?
5. Suggested skin, do we not want to require XSEDE skin of they are going to pitch it as using XSEDE's auth?
6. For the first time user on page 8. The user has to link with a globus ID as well? So they will need to have an XSEDE ID, a Globus ID and whatever local ID is on the system they are trying to auth against?
7. On page 9, what happens if the user clicks deny?
Once these are clarified I am fine with moving ahead with my approval.
Regarding your question #9, no, that’s an issue in the doc that I commented on, too. The example is kind of confused. Most people don’t—and won’t—have GlobusID identities. When Venkat was preparing the example, he must have had a GlobusID as his primary identity.
To link an identity, you have to authenticate to both the “new” one being linked and the “old” one being linked to. Many XSEDE users won’t be linking at all because XSEDE will be their first and only identity in Globus. (They will have nothing else to link to.) From then on, XSEDE will be their “primary” identity in Globus, though they might link others to it later. Those people who do already have an identity in Globus (and who choose to link their XSEDE identity to it) will probably have a campus identity, so that’s what they’ll need to authenticate to in order to create the link.
I hope that’s helpful.
Oops, that was question number 6, sorry!
IMO, question 5 should definitely be topic for pro/con discussion. I've seen other reviewers comment that they think it would be a bad idea to use the XSEDE skin because it might prime users for phishing attacks. On the other hand, not having a recognizable skin on frequently used apps might have the same effect? A related issue is that the XSEDE skin is only available to apps registered under our XSEDE Globus subscription, so they'd presumably need to be registered by an XSEDE staff member. However, Globus provides a sharing feature for app registrations that's intended to allow teams to administer/manage apps as a team rather, so we can use that. The fuzzy issue might be where the line is between XSEDE staff and XSEDE community contributors? We have one L1 SP using the skin for their resource now (Jetstream). I'm pretty sure that Wrangler has the Globus Transfer Web UI embedded in its user portal but I don't remember offhand if it's using an XSEDE skin or not. Are L2s and L3 allowed/expected to use it also? What about "partners?" Finally, there's the issue of ease-of-use and whether we want to make it harder for people to set up their apps. Without a skin, it's trivial to register an app with Globus. Adding the skin is a support ticket, I think? We could be a driving force behind making it easier, but ATM, it's still a ticket. Of course, adding the skin could be a final deployment step after the majority of testing is finished?
Sorry for commenting on these piecemeal. Regarding question 3, that’s an excellent point and it might be related to the skinning question because the ability to configure a skin is tied to the use of our Globus subscription. If we choose to require use of the skinned UI, then we’ll need client apps to be registered in a way that’s associated with our subscription. Globus’s client app registration interface allows app registrations to be managed by teams, so we’d just need to create a project in the registration interface and add the app administrators as members of that project. Then each app admin could create their own app registrations and they’d all be easy to keep track of as a group for notifications, policy checks, or staff changes.
Hi Maytal,
2. User Guide is for End-users as mentioned in Section F.1. Delivered packages.
3. This is a generic project question (list of SSO clients). One would think that there are already mechanisms in place to define a new list. I will request JP and others to offer his thoughts on this. I believe this should be intrinsic to XSEDE as opposed to riding on outside subscriptions, skins and such.
4. Button text on page 4. The text "XSEDE Single Sign-On" isn't really longer than "Other Sign In Options" that is currently being shown on the XUP sign-in page. For uniform user-experience and look-and-feel, primary objective of the design activity is to settle on a single button/text, that's also meaningful all across XSEDE.
5. Skin. "XSEDE Web Single Sign-On" will be pitched as a mechanism that uses Globus, and IdPs so on, so each entity can portray as itself without masquerading using skins.
6. Globus ID. This was my misconception which Lee has cleared.
7. User clicks Deny. This must cause authentication to fail. I will verify and update doc.
Thanks,
venkat