getsentry / getsentry/sentry

Auth - SSO SCIM Azure AD: Role assignment on Team level rather than member level.

Open
#79,910 3 comments 0 reactions 0 assignees View on GitHub
Feature Metrics Product Area: Settings - Auth Sync: Jira
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
22h 21m
Merged PRs (30d)
586

Description

### Problem Statement

In Azure AD, we have security groups for various roles within a team, such as ABC-Admin, ABC-Contrib, ABC-Read, and ABC-Guest, which are used in other monitoring platforms. However, Sentry assigns roles at the user level within a team, not at the team level.
This creates the following challenges:

* Multiple Teams for Different Roles: If SCIM is enabled, separate Sentry teams are created for each security group. For instance, two teams would be created: "ABCAdmin" (for the Admin group) and "ABCContrib" (for the Contributor group). While the "ABCContrib" team correctly assigns users the Contributor role, users in the "ABCAdmin" team are also assigned the Contributor role by default, instead of the expected Admin role.
* Manual Role Assignment for Admins: After team provisioning, organization administrators must manually change a user in the "ABCAdmin" team to the Team Admin role. Without this, the team remains without an internal admin, and the organization admin must step in to perform this task, creating additional administrative overhead.
* Limited Self-Management for Teams: This setup limits the ability of teams to self-manage their roles in Sentry. For example, the "ABCContrib" team can operate as expected without intervention, but the "ABCAdmin" team requires manual role elevation from the organization admin to ensure someone has the necessary permissions to manage the team. Although the organization admin can initially assign a Team Admin, the role assignment process in Sentry often leads to confusion and is likely to be overlooked by team admins, ultimately resulting in additional administrative overhead.

### Solution Brainstorm

*No response*

### Product Area

Settings - Auth

┆Issue is synchronized with this [Jira Improvement]() by [Unito]()

We want to define a set of [lightweight metrics]() that SDKs can automatically collect for e.g. framework, language or platform, focusing only on signals that **do NOT overlap with Tracing**. Ideally these metrics should give a quick sense of app or runtime health, … while deeper investigation will still rely on traces or profiles.

Examples**:**

* Node.js runtime metrics (e.g., event loop delay, heap usage)
* Prisma-related metrics in Next.js
* Mobile CPU / memory usage to help surface potential ANRs or app hangs

---

**Candidate Metrics (add more below)**

* …

*(please also add ideas, questions or examples in comments)*

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.