User Management
Goal: Understand the complete user and access model.
OpenX uses role-based access with workshop- and surface-level granularity. Each teammate gets a role; you can override it for a single surface.
Where users are managed
| Level | What's managed |
|---|---|
| Account | Sign-in and identity |
| Organization | Cross-workshop policies |
| Workshop | Team membership and roles |
| Surface | Fine-grained, per-surface access |
How people sign in
| Method | Notes |
|---|---|
| Email / password | The default |
| SSO (SAML, OIDC) | Sign in through your own identity provider |
| Social (Google, Microsoft) | If you enable it |
Scope: workshop vs surface
- Workshop level - a teammate's role applies across every surface. This is the norm.
- Surface level (optional) - override the workshop role for one surface. More restrictive, useful for external partners or contractors.
Single sign-on
To connect your identity provider:
- Configure your IdP (Okta, your directory, etc.)
- Provide its SAML metadata or OIDC endpoints
- Map your IdP groups to OpenX roles
- Teammates sign in through your IdP
Run it in your own cloud
OpenX runs in your tenant. When you deploy it on your own infrastructure, you own the identity layer and OpenX handles authorization:
| Aspect | Where it lives |
|---|---|
| User accounts | Your identity provider |
| Role assignments | OpenX, inside your tenant |
| History and records | Your storage |
Recorded and attributable
Every user action - sign-ins, access, changes, role changes - is recorded and attributable. See how that history compounds in Ship with Confidence.
Standards
| Standard | How OpenX supports it |
|---|---|
| GDPR | Export and delete user data |
| SOC 2 | Audit logging and role-based access controls |
Next steps
- Manage tokens and credentials -> Security: Secrets
- The two-stage change flow -> Save vs Commit