Permissions

Permission model

Permissions control access to client administration and verification functions. A user receives permissions through their one assigned role.

Common responsibility areas include:

• Users and roles.
• Branding.
• Vendor connections.
• Verification execution and review.
• License visibility and refresh.
• Activity-log visibility and integrity verification.
• Network inspection, health checks, and host-change authorization.
• Software-update status, signed release checks, and access to the exact host update command.

OneView hides navigation and actions the user cannot access and also enforces permissions when an action is requested. Hidden navigation alone is not a security boundary.

The dashboard requires authentication but no additional page permission.

Application permissions

• vendors:read permits the vendor connection list and details.
• vendors:manage permits connection creation, preferred selection, credential rotation, and enable/disable actions. Assign vendors:read as well so the manager can navigate to and review the page.
• verifications:read permits metadata-only locally stored verification history. It does not reveal normalized result fields, result-derived table previews, or verification detail views.
• verifications:results:read appears as View verification results and permits bounded result previews and stored normalized result details. Assign verifications:read as well so the reviewer can navigate to verification history.
• verifications:execute permits New Verification on a licensed Sub-module's Verification page. The history table remains read-only.
• branding:read permits the current branding profile, preview, and history.
• branding:manage permits save, logo/default changes, and confirmed history restore.
• license:read permits license visibility.
• license:manage permits online license refresh; it does not edit commercial terms.
• users:read permits the user and role lists.
• users:manage permits local user lifecycle, temporary-password reset, role assignment, and non-immutable role creation/update.
• audit:read permits activity search/pagination and automatic integrity verification.
• service_accounts:manage permits human administrators to list, create, rotate, and revoke service accounts. It does not let a service account administer credentials.

Every signed-in user can view and revoke their own browser sessions. users:manage additionally permits the all-sessions view and revocation of another user's session or every active human session. See Active sessions.

Role design

Avoid giving every user the system administrator role. Create roles around operational duties and review them when new Modules, Sub-modules, or administrative features are introduced.

The system administrator role initially includes View verification results. Custom roles do not receive it automatically; an administrator must explicitly assign it when the role's approved duties require access to sensitive stored results.

Exact permission keys are listed in the Roles interface for the installed release. Documentation for a new client function must state which permission controls it.

Service-account permissions

service_accounts:manage permits a human administrator to create, list, rotate, and revoke service accounts. Service accounts cannot use that administrative permission themselves.

API Service Accounts are not assigned dashboard roles or permissions. An active credential can call all public integration APIs made available by the installed licensed Modules and Sub-modules. It cannot use the dashboard or setup, administration, user, role, branding, network, license, software-update, or credential-management endpoints. Possessing its API key does not bypass Module, Sub-module, capacity, connection, or license enforcement. See API Service Accounts for credential handling.

Network permissions

• network:read permits current network-setting inspection and safe health checks.
• network:manage permits the same inspection plus proposal staging, cancellation, and host-command generation.

Applying an approved proposal remains an explicit host-administrator action. See Hostname & networking.

Software-update permissions

• updates:read permits viewing the installed version, last online check, available update, progress, and outcome.
• updates:manage includes status visibility and permits Check now plus viewing and copying the version-bound host update command.

Applying an update remains an explicit host-administrator action. See Updates & versions.