1439647 - Define "loginIdentity" and make it available to other views and components

Status: RESOLVED WONTFIX

(Taskcluster :: UI, enhancement)

Description

[Pete Moore [:pmoore][:pete]]

Going to https://tools.taskcluster.net/credentials, we see something like:


Credential Information
Signed In As: mozilla-ldap/[e-mail]/dev
ClientId	: mozilla-ldap/[e-mail]/dev
Type	permanent
Expires	in 999 years
Scopes	
assume:*
auth:*
aws-provisioner:*
docker-worker:*
ec2-manager:*
generic-worker:*
github:*
hooks:*
index:*
notify:*
project:*
pulse:*
purge-cache:*
queue:*
scheduler:*
secrets:*

My login identity is mozilla-ldap/[e-mail]. This is included in my clientId, but my clientId has /dev suffix, so the login identity is not explicitly mentioned.

Since I have queue:* scopes, we also can't extract it from

queue:create-artifact:login-identity/<loginIdentity>/* scope, since this isn't listed.

We should include "login identity" in the list of properties shown, so that it can be distinguished from clientId etc. This will help avoid some confusion about what the login identity is, since some scopes refer to it.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

Actually, you don't have a login id, because you haven't logged in -- rather, you are signed in using a permacred ("Sign In Manually").  That's a pretty unusual circumstance -- that feature is really only for unusual debugging purposes.

For everyone else, the login identity and the clientId are the same.  For example, if I sign in as [e-mail] (an LDAP account), I get

---

Signed In As: Dustin Mitchell
ClientId: mozilla-ldap/[e-mail]
Scopes:
...
assume:login-identity:mozilla-ldap/[e-mail]
...

---

We have a few areas of the tools site that need to know the login identity of the user, as defined by the login service.  Specifically, the client creator and the client manager.  So I think we could get away with adding some code to the AuthController or UserSession that will calculate and verify the login identity and make that available to other code.  The result could also be displayed here.

I think the steps to determining the login identity are:

 - If the user's scopes satisfy `assume:login-identity:<clientId>`, then the login identity is the clientId
 - Otherwise, there is no login identity

Note that this won't work for the case of permacreds with `assume:*` (it will give a login identity, even though the credentials aren't from a login). I think that's OK, but it might be possible to only allow login identities for some login methods (so, if you "Sign In With Auth0" you get a login identity, and if you "Sign In Manually", you don't).

Comment 2

[Pete Moore [:pmoore][:pete]]

Maybe if we "pass along" the login identity when credentials are created from other credentials, permacreds could still have a login identity. Whether it is permacreds created from temp creds, or temp creds from temp creds - eventually if we follow the chain, we should reach the originating credentials that were given by the login service, that have a particular login identity, shouldn't we?

I think if the generated credentials could inherit the login identity property, we'd have a more uniform way to present the information. Or is this a silly idea? :-)

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

Permacreds aren't the result of a login, so by definition they don't have a login identity.  Login identity just means the identifier that the login service associates with the person's user account.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

Also, I think we've made enough of a mess of this bug that it's no longer a good mentored bug!  Maybe we should just close it?

Comment 5

[:Eli Perelman]

Agreed. We can revisit or reopen if this becomes a priority.