1181001 - meta: [jonasfj-Q3-goal] auth.taskcluster.net LDAP integration

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

[Jonas Finnemann Jensen (:jonasfj)]

At a minimum I want LDAP integration...
But this ideally comes with roles and remote signature validation.
Though, I'll have to investigate feasibility of this approach first.

Comment 1

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

Jonas, did you have any design ideas here?  We need to be able to synchronize an LDAP account with the corresponding clientId(s) so that disabling or altering the LDAP account results in similar changes to the clientId's scopes within a reasonable amount of time.

My thinking is to just run some kind of periodic task within the auth service that scans all LDAP-linked clientIds (those with, say, "assume:ext:moz-ldap:*") and compares the current roles in the auth table against the expected roles based on LDAP group membership.  It seems like the only solution, but if you see something more elegant I'm all ears :)

Comment 2

[Jonas Finnemann Jensen (:jonasfj)]

Yeah, basically, we'll issue temporary credentials when you login with LDAP, you'll get scopes:
  assume:ldap-user:<email>
  assume:ldap-group:<groupId>    for each LDAP group you are a member of.

There is no need to delete anything when people a remove in LDAP.
Ideally we should remove any roles for "assume:ldap-user:<email>", but the user won't be able to login.
And AFAIK IT doesn't allow reuse of LDAP emails.

Any temp creds issued will eventually expire, we can configure the delay as we like.

IMO we shouldn't do per user roles, rather do per group roles as we generally trust people on our
respective groups, and someone leaves.

----
But yeah, when creating clients, we might want to associated with an LDAP account, so the accessToken
can be deleted when a user is removed from LDAP. Some background task could do this.
(Maybe not delete, but email some admin to go clean it up)

----
Update: I think this will happen in early Q4, we probably want to use okta SSO, and
remote validation + roles was a lot of work.

Comment 3

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

I thought one of the design goals was that a user could authenticate to both LDAP and GitHub and get the combined set of roles (rather than having to juggle different creds).

The more common change is for a user to have their LDAP groups changed, rather than simply being disabled.

Temporary credentials sounds unfortunate -- it means users will need to re-authenticate frequently (at a frequency balanced against the risk of a long expiration -- 100 years is too long, but 1 year and 1 month are probably too long, too).  My thought was that users can create new permanent clientIds at will (initially with very limited scopes, maybe just associated with Persona), then associate that clientId with various external services - LDAP and GitHub for now.  That association would add additional roles, and those roles would be adjusted dynamically depending on the external service.  With this change, there's no artificial expiration of the underlying credential, and changes propagated from the external service take effect immediately (even on temporary credentials issued from the permacred).

I think we can use Okta for authentication, and fall back to LDAP for the metadata (group membership, monitoring for changes).

Comment 4

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

Working up some notes in https://gist.github.com/djmitche/75cafeb9c2219e7fbf29

Comment 5

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

So bug 1216393 is largely complete.  However, we have a fairly complete design for login v3, which allows users to create permacreds.  As discussed, this can exist side-by-side with login v2 (in fact, the two work very nicely together).

  https://public.etherpad-mozilla.org/p/jonasfj-dustin-talks-user-auth-senarios

What is the plan for implementing that?

Comment 6

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

"That" is another bug -- Jonas is done with v2 :)