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.