Identity And Access
Enterprise identity model
Builder Insights should move toward MongoDB-managed workforce identity through Okta SSO, with app entitlements derived from trusted org signals rather than ad hoc access rules.
Core operating concerns
- who can sign in
- how roles are assigned and reviewed
- how Builder Relations membership becomes authoritative
- how exceptions and privileged access stay auditable
Target operating model
Current-state assumptions to replace
The product should not become the system of record for workforce identity or org structure.
Email domain or manually curated allowlists are not enough to prove Builder Relations membership or leadership scope.
Privileged access should be explicit, reviewable, and revocable rather than hidden inside code or one-off data fixes.
Recommended identity decisions
| Decision area | Recommended default |
|---|---|
| Workforce sign-in | MongoDB Okta SSO |
| Primary identity source | Okta identity claims |
| Org membership source | HRIS or approved org graph feeding group membership |
| App roles | mapped in an entitlement layer, not hard-coded directly from raw IdP groups |
| Break-glass admin | explicit, limited, and audited |
Decision tracker
| Decision | Current recommendation | Owner | Status |
|---|---|---|---|
| Workforce sign-in path | MongoDB Okta SSO | Identity and Security | Needs decision |
| Builder Relations org source | HRIS or approved org graph | Builder Relations Ops and Org Systems | Needs decision |
| Entitlement mapping layer | app-managed mapping from trusted identity and org inputs | Product and Application Engineering | Drafted |
| Break-glass admin policy | explicit and audited exception flow | Security and Designated App Admins | Drafted |
Builder Relations org truth
The app needs enough trusted org context to assign roles and shape visibility responsibly.
- whether a user belongs to Builder Relations
- their manager or leadership chain when role logic needs it
- whether they hold a privileged administrative exception
- when the last entitlement update occurred
These truths should come from approved internal systems, not hand-maintained app data.
- official team membership
- reporting structure
- employment status
- department or org alignment
Risk
The biggest access risk
If Builder Relations membership is not authoritative, the app can end up with ambiguous visibility, broken access reviews, and reporting scopes that leadership cannot trust.
Entitlement mapping strategy
Use Okta-authenticated identity as the basis for every app session.
Pull team and reporting structure from an approved internal org source.
Convert identity and org signals into Builder Insights roles such as viewer, advocate, manager, and administrator.
Keep admin overrides explicit and reviewable rather than relying on invisible operational memory.
Stakeholder questions to answer
Identity and security owners
- what Okta integration pattern is preferred for internal workforce apps?
- which claims and groups are approved for app entitlement decisions?
- what is the expected MFA and session-lifetime policy?
- how should break-glass admin access be handled and reviewed?
Org and HRIS owners
- which internal system is authoritative for Builder Relations membership?
- how should manager and leadership hierarchy be consumed by internal apps?
- how frequently can org membership data be refreshed?
- how should contractor or temporary-role cases be represented?
Product and ops owners
- which roles should be assigned automatically versus manually reviewed?
- which views should be scoped by role only versus by org membership and reporting line?
- how should entitlement exceptions be requested and approved?
Governance checklist
QA check
Minimum governance baseline
- document the source of truth for team membership and app roles
- define who approves admin or privileged access
- schedule access reviews for privileged roles
- log role changes and high-sensitivity access events