Access Model
Who can view, create, edit, and delete each element in Polaris
Roles
Polaris has three access levels:
Unauthenticated
Can browse read-only data: systems, components, technologies, teams, licenses, version constraints, violations, and approvals.
Authenticated (User)
Can create and manage systems, technologies, version constraints, and submit SBOMs. Can view audit logs, manage their own API tokens, and view their own profile.
Superuser
Full administrative access. Can manage teams, users, API tokens, license allow/deny lists, impersonation, and GitHub imports.
Access by Element
Operations available at each access level. A dash (—) means the operation does not apply.
| Element | View | Create | Edit | Delete | Notes |
|---|---|---|---|---|---|
| Systems | Public | Authenticated | Owner team* | Owner team* | * Superusers or members of the system's owner team |
| Repositories | Public | Authenticated | — | — | Added to systems; viewed as part of system detail |
| Components | Public | — | — | — | Created only via SBOM ingestion, never directly. Deleting a System cascades to the Components used only by that System — ones shared with other Systems are preserved. |
| Technologies | Public | Superuser | Owner team* | Owner team* | Created via the component-links queue only, by claiming an unlinked Component. * Edit/delete: superusers or members of the technology's steward team |
| Platforms | Public | Superuser | Steward team* | Steward team* | No Component required — the deliberate exception for non-SBOM-observable infrastructure. * Superusers or members of the platform's steward team |
| Teams | Public | Superuser | Superuser | Superuser | Full team management is superuser-only. A team cannot be deleted while it still owns Systems — reassign or remove them first. |
| Users | Superuser | Superuser | — | Superuser | Technical users only; OAuth users are created on sign-in |
| API Tokens | Authenticated | Authenticated | — | Authenticated | Users manage their own tokens from /profile. Superusers also manage tokens for technical users. Token value shown once on creation. An expired token resolves to no session at all — there is no degraded or read-only fallback. |
| Version Constraints | Public | Authenticated | Scope-based* | Creator* | Deleting or changing status: superusers or the constraint's creator. * Full edits and team reassignment go by scope instead: organization-scoped constraints require a superuser; team-scoped constraints require membership in the constraint's team (and in the target team, when reassigning) — creator identity isn't checked on this path. Superusers can always edit, reassign, or delete. |
| Licenses | Public | — | — | — | Discovered via SBOM ingestion; not directly managed |
| License Allow/Deny | Superuser | Superuser | Superuser | Superuser | Superusers manage the organization license whitelist. A license with no recorded decision defaults to not allowed. Bulk status updates are all-or-nothing — if any license in the batch doesn't exist, none of the batch is applied. |
| Violations | Authenticated | — | — | — | Compliance and version constraint violations; read-only for authenticated users |
| Approvals | Public | Authenticated | — | — | Team members approve technologies or platforms for their team. Superusers can record an approval on behalf of any team, bypassing the membership check. |
| SBOMs | — | Authenticated | — | — | Submitted via API; creates/updates components and licenses. The repositoryUrl must already match a registered System — submission never creates a System implicitly. |
| Audit Logs | Authenticated | — | — | — | Automatically generated; read-only |
| GitHub Import | — | Superuser | — | — | Creates a system from a GitHub repo without cloning |
| Impersonation | Superuser | Superuser | — | Superuser | Start/stop impersonation of other users |
How Elements Are Created
Not all elements are created directly through the UI.
| Element | Creation Method |
|---|---|
| Systems | Created via the UI form or GitHub import |
| Repositories | Added when creating or editing a system, or via GitHub import |
| Components | Discovered automatically when an SBOM is submitted — never created directly |
| Technologies | Confirmed from an unlinked SBOM-discovered Component via the /admin/component-links queue (superuser-only) |
| Platforms | Created via the UI form by superusers — no Component required |
| Teams | Created via the UI by superusers |
| Users (OAuth) | Created automatically on first sign-in via GitHub OAuth |
| Users (Technical) | Created via the UI by superusers for API access |
| API Tokens (own) | Generated from the profile page (/profile) by any authenticated user |
| API Tokens (technical users) | Generated via the Users admin page by superusers |
| Version Constraints | Created via the UI by authenticated users |
| Licenses | Discovered automatically from SBOM component metadata |
| Approvals | Created when a team member approves a technology or platform for their team |
| Audit Logs | Generated automatically on every create, update, and delete operation |
Superuser-Only Pages
The following pages and actions are only visible when the current user has the superuser role:
Users
User list and user detail pages, including technical user creation and API token management.
Impersonate User
View the application as another user to verify access controls.
License Allow/Deny
Manage the organization license whitelist and deny list.
Import from GitHub
Import a system from a GitHub repository on the Systems page.
Team management
Create, edit, and delete teams on the Teams page.
API Token Self-Service
Any authenticated user can generate and revoke their own API tokens from their profile page (/profile). Tokens are useful for scripting and CI pipeline integrations such as SBOM submission. Superusers additionally manage tokens for technical users via the Users admin page.
Impersonation
Superusers can impersonate other users to verify what they see. While impersonating, the UI respects the impersonated user's role — superuser-only actions and navigation items are hidden if the impersonated user is not a superuser. If the impersonated identity can't be resolved, the system falls back to the real superuser identity rather than failing the request.
API Token Self-Service
Authenticated users can generate and revoke their own API tokens from their profile page (/profile). Tokens are suitable for use in CI pipelines and scripts. A maximum of 10 active tokens is allowed per user.
Audit Trail
All create, update, and delete operations are recorded in the audit log with the user ID, operation type, affected entity, changed fields, and timestamp. The audit log is viewable by authenticated users at /audit.