Segmenting Roles

BEST PRACTICE:
Follow this guide after you have configured your User Groups!

Configuring and segmenting your role set enables you to quickly grant your users access to key features they require to perform their tasks.

This guide contains the high-level process to begin segmenting your roles and the roles that Imprivata recommends you have in your VPAM server.

The goal of this guide is to enable zero-trust access control through:

  • Strict least privilege enforcement

  • Clear segmentation of duties

  • Consistent role standardization

This document is designed for VPAM System Administrators responsible for configuring and maintaining secure access models.

Where to Begin

To start segmenting your administrative and contributor roles in the New UI, navigate to the User Management tab > Roles menu. In the Legacy UI, navigate to System Admin tab > Roles menu.

The role page opens with a list of the current roles in your VPAM server.

The first time you open this page, the list only contains the Standard User role. The Standard User role is the default User role with only the ability to log into the UI but no additional permissions. If you switch to using LDAP/S or SAML Authentication, you can change this default behavior.

BEST PRACTICE:
Do not modify the Standard User Role and keep it as the default. This serves as your least privilege starting point for a new hire who has been configured with a valid internal email address, but whose VPAM User has not yet been configured with the intended User Group and User Role.
If they log in before being given an intended User Role, they will see a special landing page which directs them to reach out to the VPAM System Admin for help.

Custom Roles and Permissions

This guide outlines several roles that follow two different approaches:

  • Task-Based Roles: Create specific roles for the tasks each Standard User needs to perform.

  • Linear Progression: Create roles by increasing permissions gradually.

NOTE:
Task-Based Roles and Linear Progression Roles have overlapping permissions
TIP:
Review both approaches to ensure you have the necessary roles for your team's goals, activities, and responsibilities.
If you do not require a certain role, map their permissions to another role and document what your VPAM server roles are permitted to do.

Task-Based Roles

This approach enables you to create function-specific roles that have overlapping permissions. This approach enforces the segregation of duties for your internal users.

This role is meant for a Standard User who can View and Edit users to reset passwords or update name or phone number.

The Internal Help Desk role requires the following permissions:

  • LOGIN_TO_WEB_UI

  • VIEW_USER

  • EDIT_USER

  • UNLOCK_USER_ACCOUNT

This role fulfills the following functions:

  • Manages vendors and vendor representatives in your VPAM server

  • Manages VPAM customer environments.

  • Approves third-party access requests without operational control

This role is meant for internal users responsible for third-party access, managers or system owners, or VPAM administrators.

The Vendor and Application Access Approver role requires the following permissions:

  • APPROVE_USER_CONNECTION

  • APPROVE_VENDOR_REP_APP_ACCESS

  • CREATE_APPLICATION

  • CREATE_APPLICATION_LABEL

  • CREATE_GATEWAY

  • CREATE_VENDOR

  • CREATE_VENDOR_AND_APP_REQUESTS

  • CREATE_VENDOR_REP

  • DELETE_APPLICATION

  • DELETE_APPLICATION_LABEL

  • DELETE_GATEWAY

  • DELETE_VENDOR

  • DELETE_VENDOR_REP

  • EDIT_APPLICATION

  • EDIT_APPLICATION_LABEL

  • EDIT_GATEWAY

  • EDIT_VENDOR

  • EDIT_VENDOR_REP

  • ENABLE_APP_GK_ACCESS

  • ENABLE_INDEFINITE_ACCESS

  • LOGIN_TO_WEB_UI

  • VIEW_APPLICATION

  • VIEW_APPLICATION_LABEL

  • VIEW_GATEWAY

This role manages credentials and secrets in your VPAM server. This role is meant for security teams managing authentication assets for your internal users and configured services.

The Credential Manager role requires the following permissions:

  • LOGIN_TO_WEB_UI

  • MANAGE_CREDENTIALS

  • ASSIGN_CREDENTIALS

  • MANAGE_SSH_KEYS

  • MANAGE_HTTP_CREDENTIAL_MAPPING

  • MANAGE_SECRET_TYPES

  • VIEW_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

  • CREATE_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

  • DELETE_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

  • EDIT_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS

  • VIEW_TASK_PASSWORD_POLICY

  • CREATE_TASK_PASSWORD_POLICY

  • DELETE_TASK_PASSWORD_POLICY

  • EDIT_TASK_PASSWORD_POLICY

This role provides full visibility into logs and audit trails. This role is meant for security and compliance teams.

The Auditor role requires the following permissions:

  • LOGIN_TO_WEB_UI

  • VIEW_ALL_HISTORY

  • VIEW_DETAILED_AUDIT

  • VIEW_ADMIN_LOG_USER_ACTIVITY

  • VIEW_ADMIN_LOG_SYSTEM_MESSAGES

  • VIEW_AUDIT_CONFIGURATION

This role manages authentication and system security policies. This role is reserved for security administrators of your VPAM server.

The Security Policy Manager role requires the following permissions:

  • LOGIN_TO_WEB_UI

  • MANAGE_AUTHENTICATION_SETTINGS

  • MANAGE_GLOBAL_AUTHENTICATION_REQUIREMENTS

  • MANAGE_BEST_PRACTICES_CHECKLIST

This role handles reporting and automation tasks. This role is meant for internal users who manage operations and reporting teams.

The Report and Task Manager requires the following permissions:

  • LOGIN_TO_WEB_UI

  • MANAGE_REPORTS

  • VIEW_TASK

  • CREATE_TASK

  • EDIT_TASK

  • DELETE_TASK

  • EXECUTE_TASK_ON_DEMAND

Linear Progression Roles

This approach enables you to clone (duplicate in the New UI) roles and grant permissions by building up from previous ones.

Keep this role as the least-trusted role. This role will enable your internal users to self-register to your VPAM without receiving any additional permissions.

The Standard User has the following permissions:

  • LOGIN_TO_WEB_UI

This role provides visibility into core objects without interaction. This role is meant for internal users who require visibility but no operational access.

The Read-Only User requires the following permissions:

  • LOGIN_TO_WEB_UI (Same as the Standard User)

  • VIEW_APPLICATION

  • VIEW_VENDOR

  • VIEW_GATEWAY

  • VIEW_USER

  • VIEW_USER_GROUP

  • VIEW_DEPARTMENT

This role allows users to initiate sessions without modifying systems. This role enables operational users requiring controlled access to endpoints.

The Session Connector User requires the following permissions:

  • All L2 - Read-Only User permissions

  • CONNECT

  • VIEW_SESSION_INFO

  • VIEW_OWN_HISTORY

  • END_SESSION

This role enables interaction with services during sessions. This role is meant for internal users actively supporting systems via remote sessions.

The Service Operator requires the following permissions:

  • All L3 - Session Connector User permissions

  • EDIT_SERVICES

  • EDIT_SERVICE_AUDIT

  • VIEW_NOTES

  • EDIT_NOTES

This role manages applications in your server. This role is meant for internal users responsible for onboarding systems into VPAM.

The Endpoint Provisioner requires the following permissions:

  • All L4 - Service Operator permissions

  • CREATE_APPLICATION

  • EDIT_APPLICATION

  • DELETE_APPLICATION

This user manages gateways and infrastructure-level components. This role is meant for advanced administrators managing platform topology.

The Infrastructure Manager requires the following permissions:

  • All L5 - Endpoint Provisioner permissions

  • CREATE_GATEWAY

  • EDIT_GATEWAY

  • DELETE_GATEWAY

  • RESET_REGCODE

This role manages internal users, groups, and departments.This role is meant for administrators responsible for your internal users' identity lifecycle.

The Identity Administrator requires the following permissions:

  • All L6 - Infrastructure Manager permissions

  • CREATE_USER

  • EDIT_USER

  • DELETE_USER

  • CREATE_USER_GROUP

  • EDIT_USER_GROUP

  • DELETE_USER_GROUP

  • CREATE_DEPARTMENT

  • EDIT_DEPARTMENT

  • DELETE_DEPARTMENT

This role has full administrative control of VPAM. This role is reserved only for highly trusted administrators only.

IMPORTANT:
This role is not meant to function as a System Administrator. The System Administrator is the only role that has access to the entire server and should be reserved for the least amount of users possible.

The Platform Administrator requires the following permissions:

  • All L7 - Identity Administrator permissions

  • CREATE_ROLE

  • EDIT_ROLE

  • DELETE_ROLE

  • MANAGE_SYSTEM_SETTINGS

  • MANAGE_AUTHENTICATION_SETTINGS

  • MANAGE_API_KEYS

  • MANAGE_CREDENTIALS

Security Considerations and Implementation Best Practices

The following permissions should be tightly controlled and limited to high-trust roles only. Assign these permissions only to Platform Administrators:

  • MANAGE_API_KEYS

  • MANAGE_SYSTEM_SETTINGS

  • MANAGE_AUTHENTICATION_SETTINGS

  • MANAGE_CREDENTIALS

  • ASSIGN_CREDENTIALS

  • CREATE_ROLE / EDIT_ROLE / DELETE_ROLE

Ensure that you never combine Approval and Execution privileges, and Audit and Modification privileges.

Other recommendations are:

  • Always Enforce Least Privilege: If the user does not need it, do not grant it.

  • Use Linear Progression Roles for Access Tiers: This enables you to simplify onboarding and clearly defines privilege escalation.

  • Use Branching Roles for Segmentation: This enforces separation of duties and reduces risk exposure.

  • Avoid Permission Overlap in Sensitive Areas: Do not combine credential management, audit access, and system configuration.

  • Clone Roles Strategically: Use linear roles as a baseline and extend incrementally; only as it makes sense for your activities.

  • Regularly Review Role Assignments: Set a review period to ensure permissions remain aligned with responsibilities.