Users, roles & permissions

Local access model

OneView v1 uses local users, server-managed browser sessions, roles, and permissions. Each person who administers or uses the browser application should have an individual local account.

• Each user belongs to exactly one role.
• A role may contain multiple permissions.
• The dashboard is available to every authenticated user.
• Navigation appears only when the user can access the related area.
• Permissions are enforced when each protected action is requested.
• Human browser sessions are not API credentials and must not be copied into scripts or integrations.

The setup-created administrator is a bootstrap identity. Its temporary password must be replaced at first sign-in before protected application functions become available. Create another named administrator for recovery rather than sharing the bootstrap account.

User capacity

The signed license defines the maximum number of active users, including the system administrator. When capacity is reached, the Add User drawer explains the limit instead of displaying an unusable form.

Disabled users count according to the active-user enforcement rules. Soft-deleted users do not appear in the active list. An administrator cannot disable or delete their own account, and the last system administrator is protected.

Users page

users:read permits the user list and role list. It shows a user's name, email, assigned role, and active/disabled status. users:manage adds Add user, profile management, role creation/editing, password reset, status changes, and deletion.

To add a user:

1. Enter the person's full name and individual email address.
2. Set a temporary password of at least 12 characters and deliver it through the client's approved secure channel.
3. Assign one existing least-privilege role.
4. Create the account. The user must replace the temporary password after sign-in.

The form's invite action creates the local account; do not assume that it securely delivers the password. Never send a temporary password in the same email, ticket, or chat thread as the account details.

The user profile contains:

• Password & Security — reset to a new temporary password or delete another user after confirmation;
• Role & permissions — change the assigned role or active/disabled status; and
• Logs — search and page through activity attributed to that user.

Deleting a user ends access and removes the account from the active list while retaining activity history. It cannot be undone from the application. The current user cannot disable or delete their own account, and server protections prevent removal of the last system administrator.

Roles & permissions page

users:read permits role, permission-count, and assigned-user-count visibility. users:manage permits creation and editing of non-immutable roles. Built-in immutable roles cannot be edited, and the current page does not offer role deletion.

A safe starting pattern is:

• Verification metadata reviewer — verifications:read only.
• Verification result reviewer — verifications:read and verifications:results:read after the client approves access to sensitive stored results.
• Connector administrator — vendors:read and vendors:manage.
• Audit reviewer — audit:read.

Treat those as examples, not universal legal or segregation-of-duty conclusions. Add other permissions only after the client owner confirms the task requires them. Review the complete permission reference and check assigned-user counts before changing a role because updates affect every user assigned to it.

The setup-created system administrator initially has View verification results. Existing and newly created custom roles require explicit assignment; access to verification metadata or execution alone does not grant stored-result access. Review result access periodically and remove it when a person's duties no longer require it.

Passwords and sessions

Temporary-password users must replace their password after signing in. A successful password change revokes older sessions. Production access requires HTTPS.

Sessions are server-managed and revocable. Disabling or deleting a user, resetting or changing a password, or changing a user's role invalidates affected access rather than waiting for the session to expire.

Each signed-in user can open Settings → Security to review their active browser sessions and revoke a selected session or every session. A user with users:manage can switch to the all-sessions view and revoke a selected user session or all sessions. Revoking the current session signs that browser out.

See Active sessions for the displayed metadata, revocation scopes, and incident-response guidance.

Application-to-application access

Service accounts and API keys are available for client systems that call supported APIs without a person using the browser. Service accounts are separate from dashboard roles and support an optional expiry, last-used tracking, credential rotation, and immediate revocation. An active credential can call all public integration APIs made available by the installed licensed Modules and Sub-modules, but cannot call dashboard or administrative endpoints. Do not automate calls with a local user's email/password, browser cookie, or copied session value. See API Service Accounts.

Host-authorized administrator recovery

Administrator recovery is a last-resort host-authorised operation. Confirm the target is an existing system administrator, coordinate a maintenance window, and use the approved workflow for the exact installed version. After recovery, replace the temporary password immediately and review active sessions and activity logs. See Administrator recovery.

SSO boundary

OIDC/SAML SSO and directory synchronization are deferred. The current release does not expose unfinished SSO settings and does not accept identity headers from a reverse proxy as authentication.

Future SSO support will preserve the user, role, permission, and session controls documented for OneView. Host-authorised local recovery remains available, and service accounts remain separate from human SSO identities.

Recommended roles

Create separate roles for system administration, vendor administration, verification execution, review, and audit. Grant only the permissions required for each responsibility.

Review local users and role assignments periodically, immediately disable departed users, and revoke affected sessions.