Hi Lee,
I have gone over the Globus Auth spec and have the following questions/notes:
1. Section 3.1 says: "one identity may be linked to any number of other primary identities, and thus Globus accounts.". Although this has currently not been implemented, when implemented, I am wondering which Primary Identity is selected when a user logs in using an identity that's linked to multiple Primary Identities?
2. Typo: eduPrinciple should be eduPrincipal
3. Typo: authenticates Globus Auth -> authenticates "to" Globus Auth
4. section 4.3 confusing: first para asserts account creation and 2nd para doesn't.
"For some identity providers, when an unlinked identity authenticates to Globus Auth, an account will automatically be created with this identity as the primary. For other identity providers, Globus Auth will prompt the user to create an account or link the identity with another account."
How is this decided?
5. Typo: Replace "that that" with "that"
6. How do changes in XSEDE's userinfo for a deleted or modified user flow to Globus Auth if the user always uses a campus credential to sign in?
Thanks,
venkat
Hi Lee,
A couple of notes on the above:
Meant to say: "Typo: Principle should be Principal" as in eduPersonPrincipal
I believe question 6 was answered by you in a different thread as below:
"weblogin gets them from a user profile API hosted at api.xsede.org
<http://api.xsede.org>, I think. If my recollection is correct, weblogin
caches the results from the profile API (with an expiration, I assume)
so if the profile API can't respond for any reason, it uses the last
available data."
If not, please clarify.
Thanks,
venkat
1. It isn't implemented, so there isn't an answer. :) At the moment, identities can only be linked to one primary identity and if you try to link a linked identity to a different primary identity, Globus says it's already linked and has to be unlinked before it is available for linking to a different identity.
2 & 3. I'll pass these edits along, thanks.
4. I'll ask about this and let you know when I get an answer. (My own experience as a user has been that the latter behavior always happens, but I suppose I could simply be not using the kinds of identity providers that result in the former behavior.)
5. I'll pass this along.
6. I will ask about the deleted identity part because I don't know the answer to that. In fact, I'm going to ask about both parts just to be sure I know exactly how it works. I'll let you know when I have an answer to these as well as #4 above.
Regarding your question #4, the development team confirmed that the first paragraph is correct and the second paragraph is incorrect. It looks to me as though someone meant to replace the second paragraph with the first and forgot to delete the second one. I'll add it to the list of things to be fixed in the document.
Regarding your question #6 (which is actually two questions):
When someone authenticates to Globus using an IDP and Globus generates an identity record--regardless of whether it's a primary or a linked identity--Globus has no way of knowing when the IDP invalidates the user's identity. Obviously, the user won't be able to authenticate using that identity any longer. But if that identity was linked to others, and the user can still authenticate to the others, Globus will continue to carry along the identity record from the IDP that no longer recognizes them.
One indirect way that Globus can find out about a "revoked" identity is if the IDP reuses the username and someone else authenticates to Globus using it. Because the new person will have a different IDP-specific identifier (guaranteed to be unique per OIDC), Globus will know that the username was reused. So far during Globus Auth's service run, we've experienced several false positives (where the username wasn't reused and still belonged to the original person but the IDP changed the identifier for one reason or another), and no instances of an actual username recycle. But the bottom line is this: without changes to Globus or out-of-band communication, Globus will never learn of someone's identity being "revoked" by an IDP.
For the question about changed attributes in an identity, the answer is that Globus only learns about changes to an identity's attributes when the user authenticates using the IDP for that identity. So if the user authenticates in Globus with IDP #1 one time and links that identity to another one from IDP #2, and from then on only authenticates using IDP #2 and never IDP #1, Globus will never see changes to the attributes from IDP #1. Obviously, if the user becomes aware of this and wants to fix it, all he/she has to do is authenticate using IDP #1 again.
Perhaps the user can be forced to authenticate with the "Required IdP" once every year or so?
Hi Venkat. FYI, the corrections/edits you noted for the Auth API specification in points 2, 3, 4, and 5 have been fixed online. Thanks for letting us know about them!