GoAlert: AD Based Access control to OIDC Authentication and Authorization

[sivtechrepo]

GoAlert is doing exceptionally well with managing the on-call and its features. There seems to be apprehension about the modification of existing on-call management accidentally/unauthorized. So it's imperative to do enhance the GoAlert with some level of authorization to get the GoAlert to the next level.

What problem would you like to solve? Please describe: All features such as Services, Escalation policies, Schedules, and Rotations could be modified by any logged-in person of the organization (OIDC authentication)

Describe the solution you'd like: Add Active Directory (AD Group) authorization for each of the features(Services, Escalation policies, Schedules, and Rotations) so that only members belonging to the AD Group have edit access and prevent editing of unauthorized persons. Make the AD group be optional so whoever needs the access to be controlled can control it and if someone needs to use the existing system as it is, let them also continue to use it. Since all 4(Services, Escalation policies, Schedules, and Rotations) features are independently created and managed, so it is required for every create/edit form need to get updated with AD Group. Every feature(Services, Escalation policies, Schedules, and Rotations) associated with AD Group and decides whom can edit the features

Users who have access will get the Edit/Delete icon all others will have only read-only access User with Edit/Delete Access, meaning a user who belongs to the AD group User with Read Access, meaning a user who doesn't belongs to the AD group

[sivtechrepo]

FYI @mastercactapus

[mastercactapus]

This sounds similar to #700. We recently had an internal discussion about this.

One concern is to associate GoAlert users with their Active Directory ID correctly. It also feels like a problem that should have a solution even when LDAP isn't used for auth.

---

One of the current ideas is to use an ownership-based model based on assignment. Anyone assigned to a service (i.e., by escalation policy, schedule, or rotation assigned) would be part "owner" and could make changes. Admins would be exempt, and any resources without anyone assigned could be updated by anyone (until a user is added).

Just an idea at this point, and some other details need to be ironed out, such as what happens if you unassign yourself by accident and lose access, etc... Ideally, we'd like to avoid direct LDAP integration, but not at the cost of significant overhead (i.e., having to manage groups in GoAlert separate from AD) though it's not entirely off of the table.

Thoughts?

[morawat]

Do we know by when this feature will be available? This is a very critical issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.