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.