E.2.5 Interop requirements

3 posts / 0 new
Last post
E.2.5 Interop requirements

Section E.2.5 is unclear about what's required for identity mapping.  It first shows the entire id_token and the available fields (which is good), then it says that the preferred_username field can be used to map the XSEDE username to a local account. But then it says that the "sub" field (a Globus-issued UUID) must be used. So what's the requirement?

I'd recommend that the requirement be stated as a list of options, instead. 

First, if the application allows it, the best identifier to use would be the "sub" field (the Globus-issued UUID). This is guaranteed to not change as long as the user is registered with XSEDE. Changes to the XSEDE username and email addresses won't affect the mapping.

The next-best choice would be the preferred_username field, which has the XSEDE username. This is guaranteed to not change UNLESS XSEDE changes the user's username, which happens only very rarely, I think?

If neither the sub nor the preferred_username fields are options for the application, as a LAST RESORT, the application could use the email field, which will contain the email address from the user's XSEDE user profile.  This is a bad choice for several reasons, not least of which that the chance that the user will change his/her email address in the XSEDE user profile at some point (and thus break the mapping to a local account) is unacceptably high. Another reason: Globus won't know about changes to the XSEDE-registered email address until the user authenticates using the XSEDE username/password, which the user might not do for a very long time if he/she is accustomed to using campus credentials instead. For these reasons, applications should only use the email field for mapping when no other option is available and when they are prepared to deal with frequent user login issues caused by changing email addresses.

Delivery Effort Stage: 

I think XSEDE should track users both by the Globus supplied UUID and the XSEDE username which, per Jim Basney, will not change. This way, XSEDE can make sense of the user entries and also XSEDE will have an independent way of moving away from Globus in the future, if needed. v1.1 of the design doc proposes this.

The new Section E.2.5 addresses my concern and is clearer.  I also agree with your point about not relying exclusively on the Globus-supplied UUID, and that is also described more clearly in the new version of the doc.

Log in to post comments