Version 1.1 of section E.2.5 is more extensive than the previous version and introduces new requirements. As stated in version 1.1, all of the points listed are required from all clients.
Many of our clients are implemented using off-the-shelf OIDC plugins that don't provide XSEDE-specific functionality. (This is a benefit of our design because it makes adapting client applications much easier.) Putting a bunch of XSEDE-specific requirements on clients makes it harder to adapt client applications to XSEDE, which seems like a bad thing. I don't believe that all of these are necessary.
I recommend that this list of requirements be paired down significantly to include only the bare minimum that are necessary to ensure the application works with XSEDE and is secure. The remaining items should be left as an additional set of recommendations that should be implemented when possible, but not if it means the difference between an application being able (or not able) to use XSEDE Web SSO.
Item (a), for example, is a very good practice and would guard against one known corner case in using Globus for Web SSO. However, I'm not aware of OIDC plugins for applications that can provide that functionality. (E.g., Moodle, Drupal, WordPress, Atlassian apps.) Rather than exclude these or force XSEDE operators to fork the plugin code and maintain their own XSEDE-specific versions, it would be better in my opinion to allow some flexibility.
Same argument for (d) and (e).
I am unaware of a specific requirement driving item (f) in the list. Is it truly necessary? What requirement does it satisfy?
Item (g) seems to preclude application-specific user profiles. Again, is this truly necessary? Why don't we want to allow individual applications to allow users to have their own profiles specific to the application? Why shouldn't I be able to set the email address used by a Moodle training site to something different than my XSEDE user profile?
Hi Lee,
I personally have no experience with any of the OIDC plugins you mentioned. I was hoping the plugins themselves would provide a way for a sub-plugin to be developed. I would be interested in hearing from Kate as well, since she seemed to have experience with Drupal/Confluence.
Item (f): I think I heard this from Jim Basney and also it would be good for the user to know what identity they are signed-in as.
Item (g): this was more an attempt to make sure things stayed in sync with their XSEDE profile, but perhaps it would be fine for a user to have some specific info for each app as you suggest.
Thanks,
venkat
Hi Venkat,
We’re using version 7.x-1.0-beta8 of the openid_connect module with XSEDE specific modifications, including a patch for auto account matching and connecting.
The edits I made to the Drupal module were mainly to pass the XSEDE user id to the "UserInfo Endpoint" that returns user information (https://auth.globus.org/v2/api/identities/<user_id>). The module originally only passed the access token to the UserInfo Endpoint, and XSEDE’s also requires a particular user id or username.
I also edited the Drupal module to map the first and last name returned from the UserInfo Endpoint to the Drupal first and last name fields. Drupal doesn't create real first and last name fields by default, so the machine names of those fields are what I chose when I created the name field from the admin menu under “Configuration->People->Account settings->Manage fields”.
My notes on the interoperability requirements in section E.2.5 for Drupal (CSR site in particular) are:
a. check to make sure 'identity_provider_display_name' is set to 'XSEDE'.
There is currently no check that 'identity_provider_display_name' is set to 'XSEDE', though it wouldn't be difficult to add this in.
b. Determine “XSEDE Username” from 'preferred_username' by excluding the trailing ‘@xsede.org’. This is the user’s current XSEDE portal username.
We currently make the Drupal username the entire 'preferred_username' field (we don't strip @xsede.org). This would also not be difficult to change. The username, email and real name fields are updated each time a user logs into the CSR based on what is returned from Globus. The Drupal account has a unique user id that is mapped to the Globus 'sub' id to make these updates.
c. track users primarily by 'sub' value which is a UUID specific to the user’s linked XSEDE identity that Globus assures will never change, and secondarily by “XSEDE Username”.
We associate Drupal users by their Globus 'sub' value and don't have the same association for the Globus 'XSEDE Username'. Since the 'XSEDE Username' may change, I'm not sure it's worthwhile to modify the existing code for this.
d. update local XSEDE username with “XSEDE Username” from item ‘b’, for the entry that matches UUID, if the usernames are different. This is to update the local database with a changed username for the same user.
Yes, we do this each time a user logs in.
e. update a NULL UUID with the value from 'sub', if local username matches the username from item ‘b’. This is to start tracking the user by UUID, the first time the user logs in using Globus Auth.
We did apply a patch for auto account matching as described above.
f. indicate the logged in user by displaying “XSEDE Username” from item ‘b’.
We have a "My Account" link in our primary navigation that displays information about the logged in user.
g. display 'name' and 'email' as non-editable (view only) items, if the XSEDE client wants to display them.
We currently allow users to edit these fields, but as they are overwritten by Globus values upon login, edits are essentially lost. I could add code to make them non-editable to anyone but admins.
Kate
Thanks for the info, Kate. A few questions:
1. I am a little confused in regard to Userinfo. It looks like Globus Auth supports the standard Userinfo Endpoint at /v2/oauth2/userinfo which is documented at:
https://docs.globus.org/api/auth/reference/#get_or_post_v2_oauth2_userin...
which should be returning userinfo when the appropriate access token is sent in the header.
I must be missing something. I am curious to know if there were difficulties with the above approach, forcing use of the identities resource, instead of the userinfo endpoint.
2. I see Auto account matching is using the email value. I guess this could be changed to use the preferred_username value right?
3. If you aren't stripping @xsede.org from preferred_username, I wonder how it would match any accounts created outside of Globus Auth, which may NOT have the @xsede.org suffix?
4. In regard to 'c': Per Jim Basney, XSEDE usernames don't change, although code-wise, we would want to continue to update to the latest username we see from Globus. The reasoning for having the XSEDE username stored along with the UUID, is so that (a) XSEDE can make sense of user entries in its own tables independent of XSEDE and also (b) XSEDE would have a way to transition over to a different system from Globus Auth in the future.
5. I guess since any user profile changes are overwritten, it might make sense to disable editing, unless as Lee suggests, profile changes are NOT overwritten if a flag is set denoting explicit user changes to the profile?
6. Lastly, I think the client setup guide should point to patches and guides that are specific to the specific OIDC plugins (such as the one for Drupal) both to ease deployment and also for more standardized implementations across XSEDE.
Thanks,
venkat
Not all providers of Web services to the XSEDE community have (nor should they be required to have) a Kate standing by to make changes to their OIDC plugins, nor will they necessarily have the staff continuity to ensure that those changes are properly maintained when the upstream provider comes out with a new version. A key benefit of choosing OIDC for our Web SSO design is that it offers a plethora of available OIDC plugins for apps. If we turn around and say, "We're going to use OIDC but none of those plugins are good enough," it defeats the purpose.
For example, the Moodle training service provider at Illinois has already told us that she needs to pass along really minor/modest suggestions about the Moodle OIDC plugin to the authors of the plugin, who she doesn't know personally. She has no control over whether they make those changes or not. Consider someone using XSEDE's Web SSO mechanism to enable logins to a community website or blog based on WordPress. They're surely not going to be programmers! If we really want to enable researchers to do interesting things with this service, we need to make it accessible to non-programmers.
I don't think we should build into our design the assumption that people will be making custom OIDC plugins for their applications. It's not so much the initial change that is the cost I'm worried about. It's the maintenance over time where we'll see bad things happen. Most typically, people will be reluctant to apply updates (which might address security issues) because they'll have to spend time reapplying their XSEDE customizations.
To be clear: I didn't say we should remove these ideas from the design doc. I said we should recast them as suggestions or best practices. The stricter we make the user requirements in the design, the fewer people will be able to use the service. Or, people will simply start ignoring what the design doc says, which has its own downsides.
I agree with Lee. Our design should be implementable using existing OIDC clients and not require custom code. -Jim
E.2.5 has been radically modified to reflect the changes suggested in v1.2. Thanks.