Identity.Base Docs
Identity.Base.Admin
`Identity.Base.Admin` adds opinionated operator endpoints for users, roles, and permissions. Use it when you want a management surface without building your own admin CRUD layer on top of the core and RBAC packages.
What it adds
- `/admin/users` for listing, creating, updating, locking, soft deleting, and restoring users.
- `/admin/roles` for listing and managing roles.
- `/admin/permissions` for querying the canonical permission catalog.
- Permission-based authorization helpers so admin routes enforce both scope and fine-grained permission checks.
Runtime requirements
- Admin scope: by default the token must include
identity.admin. - Permissions: the caller also needs values like
users.read,users.manage-roles, orroles.manage. - RBAC package: this package sits on top of `Identity.Base.Roles` and reuses its storage and claim pipeline.
| Route family | Examples | Permission |
|---|---|---|
| User management | GET/POST /admin/users, PUT /admin/users/{id} | `users.read`, `users.create`, `users.update` |
| Account lifecycle | lock, unlock, force-password-reset, resend-confirmation, mfa/reset | `users.lock`, `users.reset-password`, `users.reset-mfa` |
| Role assignment | GET/PUT /admin/users/{id}/roles | `users.manage-roles` |
| Role catalog | GET/POST/PUT/DELETE /admin/roles | `roles.read`, `roles.manage` |
| Permissions catalog | GET /admin/permissions | `roles.read` |
Operational guidance
- Grant the admin scope only to trusted operator clients such as a management SPA or internal admin app.
- Seed at least one administrator role with the user and role permissions needed to bootstrap the system.
- Admin routes ignore `X-Organization-Id` on purpose, so they always operate across organizations.
- The optional service-principal package adds its own `/admin/service-principals` route family and permission set on top of this admin/RBAC foundation.
- If email actions fail, the admin API is only surfacing the same underlying email sender used by the core host.