Let's think differently about people who leave Mozilla

IAM
#1

In the past before the IAM project began, when a Mozilla employee left the company we disabled their LDAP account. Doing this revoked their access to all of the internal websites that used LDAP for authentication and retained their access to the external websites that didn’t use LDAP for authentication.

We did this because there was a clear line between internal and external sites, delineated by if they used LDAP for their identity lookups. By disabling the user’s LDAP account we were accomplishing a very blunt method of authorization change by revoking access to websites that we thought of as “for paid staff only, not contributors”

Fast forward to today.

We now have the capability for staff and contributors to both access all websites and the notion of internal and external websites is gone.

The problem is that we’re continuing to rely on the crutch that we used in the past where we disable a user’s LDAP account when they transition from being a paid Mozilla staff member to a unpaid contributor despite the fact that we no longer need to.

The reason we’re relying on this crutch is that allows us to defer answering the hard question of “What type of access should a person have to a resource that is currently only accessible by paid staff once that person transitions from being a paid Mozilla employee to an unpaid contributor?”

We should start thinking about the event of a person transitioning from paid staff to unpaid contributor in the same way we do all other authorization changes and get out of the business of disabling LDAP accounts. When a user changes teams at Mozilla, this event is reflected in an authorization change involving being removed from some IAM groups and added to other groups. When a contributor begins working on a new project, this is reflected in an authorization change of the user being added to a new group. The event of a paid staff member becoming an unpaid contributor should work just the same way, with the user being removed from relevant IAM groups, not by their LDAP account being disabled.

The deprovisioning actions that currently trigger when an LDAP account is disabled shouldn’t be triggering on LDAP account disablement but instead on a change in group membership of a user.

In this model we need to prompt websites to think about the hard question above, consider the data classifications of their data, and join us in the future where staff and contributors should be treated much more similarly from an access perspective than they have in the past. If their data is meant to be accessible to Mozilla Staff and NDA’d Mozillians, then they need to grant access to that group instead of constraining access to paid staff as a legacy of the missing IAM capabilities of the past.

I propose that we

  • Consider if we collectively support this approach
  • Discuss the technical steps that would be necessary to move to this model
  • Identify the RPs that either need to assert that their data is classified as Mozilla Workgroup Confidential and what groups should have access to it, or that their data is classified Mozilla Confidential Staff and NDA’d Mozillians and open up access to all the members of that group
  • Communicate with these RPs to find out how much time they need to adopt this change
  • Communicate with Mozilla paid staff teams to find out how much time they need to begin using and maintaining groups and those groups’ memberships to assert who has access to what
  • Based on RP and team responses, define a timeline of when we’ll stop disabling LDAP accounts and instead make group membership changes (if any are appropriate)
  • Update process and workflow docs when the time comes and transition to ending LDAP account disabling and move to group membership changes to signify the transition of a person from paid staff to unpaid contributor

I’d like to hear folks’ thoughts on this.

2 Likes
#2

Employees LDAP accounts are strongly tied to official Mozilla emails which must be terminated when the employee exits.

I don’t think the termination of the LDAP account is the root of the issue though, the transfer of privileges is.

Privilege transfer:

For the transfer of privileges to work safely, yes, all group data has to have their data classification access documented for all RPs and all accesses. While this is technically doable as you expose, this also assumes that all RPs will be well managed and keep on being well managed in the future, vs only having the account termination well managed.

In other words: many places to keep well managed, vs single place.

Some data about RPs would help:

If you can come up with the list of all RPs and their expected data classification for access, I think that would give us enough data to figure out if we can implement the privilege transition safely enough (ie qualify what the risk of the change is and discuss how to implement it in more details)

#3

I think you are right to bring up the issue for re-examination now that we have additional capabilities and we don’t really want folks to ‘leave Mozilla’, but just change their status: Staff to NDA’d contributor.

I think focusing on the LDAP/Not LDAP component is a bit of a distraction however. We might be better served by framing this as a user story/journey and letting the technical controls follow along? As Kang mentioned, there are some realities (@mozilla.com email must be removed, LDAP/licensing limitations, etc) to work around; but we should aim to statisfy the user/staff who is transitioning.

#4

I made the transition from Mozilla staff to NDA’ed contributor 2 years ago and losing access to a whole lot of stuff together with my @mozilla email (including the awesome alias) was one of the hardest pieces of it. Thankfully, I’ve had Mozilla LDAP for hg access with my private email for a long time since even before I got on staff, and had tied a lot of stuff into that, which helped - but I agree it would be nice to be able to make that transition much smoother as we don’t want to lose (most of) those people from the community (“once a Mozillian, always a Mozillian” as cbeard likes to say).
One of the largest issues is probably, as @kang mentioned that the @mozilla.com email is tied to the account and we remove that email. Once there was discussion about being able to have some kind of Mozilla community email accounts for the core contributors, something like that may offer a solution - or accounts being able to be transferred to a different email.

#5

Note that non-LDAP account can get similar access to LDAP account on the current IAM platform - with a few exceptions such as Mercurial access.

As we’re also adding Firefox Accounts, and unless there is any effort toward hosting “Mozillian emails”, using these accounts with one’s own private email seems like a good solution, as long as:

  • we find good technical solutions to transfer certain privileges (i.e. with a non-terrible UX, and a process that can be trusted)
  • we migrate the remaining bits & pieces that purely rely on LDAP accounts (mainly Mercurial access)
  • potentially additional things I’m not aware of?

Mentionning @gps for the Mercurial part of this ^

Note: one is/would still be free to have additional accounts and handle them however they please, i.e. if one wants to have a private account completely separated from a staff account and have them never merge, associated, or have privileges transferred between them that would always be possible (and in fact, it would be easier if there is no dependency on an LDAP account)

1 Like
#6

How would RPs be expected to handle this transition if, presumably, a user’s email and user_id would be changing?

#7

How would RPs be expected to handle this transition if, presumably, a user’s email and user_id would be changing?

I think they effectively become new users with potentially similar (but different) access (ie you do lose the “linked” history)

#8

(Might be skipping ahead too far into technical nitty gritty here) but could we add a field to profiles so that RPs where the above would be an inconvenience for users (like Discourse) could migrate that linked history over?

Something like former_sub or former_email (or possibly both).

#9

Something like former_sub or former_email (or possibly both).

Yeah I was also wondering if it would be a good idea to have something like including a verified email for the account that is no longer reachable, at the minimum - which might achieve that - or something similar.

The point is that when you let go of your Staff account, no matter what, permissions have to be looked at for the transition, and you’ll lose the email account, and access to certain NDA documents, and so on and so on.
Due to this in most cases I believe you cannot have the exact same account, and we just want to make the process as painless as possible.

This means having the value would only be useful for specific RPs where the implementation of the transition should be done very carefully. Maybe even just a thing in your profile that says "When I was Staff I used to be ", though in certain cases it may be ok to basically tie/replace the profile so that it looks like “you never left”. We’ll definitely need to ask advices from our HR, legal, etc teams at Mozilla to ensure we do this properly though.

#10

In the case of a Discourse, the value lies in keeping your username, category subscriptions, post history, and various other preferences and statistics. I imagine there’s similar value on other RPs.

Removing the team_moco/team_mofo group from a user’s profile would be sufficient to remove their access to NDA categories, since groups get updated every 15 minutes. Isn’t this how all RPs should behave?

#11

RPs use either user_id or primaryEmail to identify users. Additionally, some parse the email address to find out if you’re team_moco for example, which is bad practice, but does happen.

If an RP uses the primaryEmail for identifying users, then as the mail would have to change, it won’t be transparent. If an RP use the user_id instead, because of how they’re hard coded by Auth0 ("ad|blahblah..") it will also change when the primaryEmail/login method changes. Basically, we can’t just remove the groups in that model, or at this time. Whenever we’re able to modify user_id this might become an option though

#12

Apologies, I wrote somewhat in shorthand, that second paragraph was in response to:

If an RP were to transition an existing RP account with use of the former_email field, wouldn’t current requirements dictate that in all cases it would be ok to basically tie/replace the profile so that it looks like “you never left”, since that new IAM profile wouldn’t contain the groups which grant access to secret stuff (or at least employee secret stuff).

I’m imagining here that the existence of the former_email field in an IAM profile would make compatible RPs find the RP account associated with that former email, and update the user_id or primaryEmail to match the new IAM profile, before logging the user into that RP account.

#13

@leo I think my answer is still the same though, unless I missed something. The RPs would have to handle this in the way they believe is safe, and most RPs would probably not handle it. For the ones that do, as long as they verify what they do is safe, you could definitely have continuity that way.

Note that the field would most likely be something like emails[] {name: former_email, value:..., etc.} instead of just a former_email field (ie utilizing what we have)

1 Like
#14

Okey-dokey, I am going to stick my 2-cents in here. Might only be worth 1-cent, actually.

I saw this thread a bit back and it obviously stuck in my old brain and now I wish to see if maybe all the technical stuff about protecting secrets and associated discussion could be set aside, for a moment.

Stay basic with the main idea, first.

You don’t want to alienate those that did fine work for the Mozilla Community, but have to move on. You want them to know that once a Mozilla, always a Mozilla and so they can still have certain privileges minus the ones that are going to be a problem for keeping secrets.

So first make it a flat YES/NO we will keep them in the fold, — then throw in the BUTS.

You folks have to excuse this old man who thinks in that way. First a flat YES_!_ COOL_!!_ (Italic font ain’t working.) Then get into what might have to be taken care of to satisfy security concerns.

I don’t see those flat out YES thingies showing right away in the responses above. You go right into the tech stuff without first throwing a big Hug around the life members of Mozilla.

These folks you are discussing know full well there are going to be technical issues that have to be dealt with, but if the flat out YES answers show themselves a whole bunch right in the beginning of each member’s 1st post here it is like a Mozilla Hug, yes?

See, I told you it was only worth a penny.

But which nation’s penny? And if it is a very old penny like me, it gets more valuable, no?

#15

Yes No

@michaelsensei I assume that there is agreement on this but if not I’ll put my position here on will “we keep them in the fold” : Yes

  • What enabled Mozilla to compete with the big guys is our contributors
  • Preventing someone who’s proven themselves committed to Mozilla to the point of working for Mozilla from contributing after they’ve left by putting up any barriers is foolish
  • Historically these barriers have been driven by a lack of technology to enable contributors to engage in the same was as staff, thankfully those barriers are almost completely gone now
  • This event, transition from staff to contributor, unfortunately remains modelled on the old tech stack which is no longer necessary

Clarification of terms : NDA

Without getting too far into the technical discussion above between Leo and Guillaume, I would like to call out some clairifciation of terms to make sure we’re all talking about the same reality

when you let go of your Staff account, … you’ll lose … access to certain NDA documents

Well, probably not NDA documents, since hopefully part of leaving Mozilla is becoming an NDAd mozillian. Do you mean it’s possible when leaving that you lose access to some Mozilla Confidential - Specific Work Groups Only documents?

Removing the team_moco/team_mofo group from a user’s profile would be sufficient to remove their access to NDA categories

Hopefully there’s a way in discourse for user’s who are NDAd Mozillians to see NDA categories that doesn’t involve them being members of team_moco/team_mofo. Is there?

I worry that in this thread we’re conflating the phrase “NDA” to mean “employed by Mozilla” which we shouldn’t.

groups which grant access to secret stuff (or at least employee secret stuff).

Are there any examples of data which we’ve classified as Mozilla Confidential - Specific Work Groups Only where the work group is people employed by Mozilla? I’ve not encountered this before.

The proposal

I’d like to encourage folks to respond to @michaelsensei 's question if indeed we support the desire to keep staff-turned-contributors in the fold.

Consider if we collectively support this approach

It sounds like there’s support of this general idea from those that have responded. Indeed this transition event may manifest in something more nuanced than either disabling or not disabling an LDAP account.

In the absense of objection here over the past couple weeks, I think we’re clear to move forward.

Discuss the technical steps that would be necessary to move to this model

Some of this has been floated here. I feel like this would benefit from a more in depth realtime conversation. With Mozilla All Hands being next week, I’ll see if I can setup a time and place where we can have this initial dicsussion. I’ll send out a time location and doc if I manage to make it happen.

Identify the RPs that either need to assert that their data is classified as Mozilla Workgroup Confidential and what groups should have access to it, or that their data is classified Mozilla Confidential Staff and NDA’d Mozillians and open up access to all the members of that group

I think this is just a data gathering process that I’ll probably need to do with relying parties. I’d expect to start this after all hands.

1 Like
#16

Absolutely, they just have to be members of the Mozillians.org NDA group.

It gets a big :+1: from me!

1 Like
#17

As an aside, here’s an example of one impacts of how we currently transition users from staff to contributor : All mana documents from users that have transitioned are no longer findable with search.

1 Like