For the complete documentation index, see llms.txt. This page is also available as Markdown.

Jira Workflow

Keeper vault integration for request-based access management through Jira issues.

About

The Keeper Security Integration for Jira is an Atlassian Forge application that enables seamless management of Keeper vault operations directly from Jira issues. This integration bridges the gap between project management workflows and secrets management, allowing teams to request, approve, and execute credential operations without leaving their Jira environment.

The Jira integration also provides management over Endpoint Privilege Manager (KEPM) approvals and SSO Device Admin approvals via tickets created by the companion ITSM app. The vault supports both NSF (Nested Shared Subfolder) and Classic modes. All actions are logged as Jira comments with timestamps and user information.

Record Management Features

Feature
Description

Create New Records

Add credentials, secure notes, payment cards, and custom record types

Update Records

Modify existing vault records with new information

Share Records

Manage folder-level access for teams and users

Manage Permissions

Control granular access rights for records in shared folders

Share Folders

Manage folder-level access for teams and users

The vault defaults to NSF mode. Check "Use classic permission model" to switch to Classic mode. Records and folders display NSF/Classic badges in picker dropdown. NSF mode uses role-based permissions, while Classic mode uses individual permission checkboxes — see Vault Modes and Permission Models for the full role list and flag reference.

Endpoint Privilege Management Features

Feature
Description

Real-Time Approval Workflows

Review and approve privilege elevation requests from endpoints

Live Request Monitoring

View pending requests with countdown timers and detailed context

One-Click Actions

Approve or deny requests instantly with full audit trail

Comprehensive Request Details

User identity, application, justification, and expiration status

Prerequisites

To maintain Keeper's strict zero knowledge encryption model, the Jira integration requires that the customer hosts the Commander Service Mode container on a VM and hosts the customized Forge app in their Jira Cloud.

Requirement
Description

Keeper Commander Service Mode

A service account running Commander Service Mode with REST API access through Ngrok or Cloudflare Tunnel for routing requests.

Jira Cloud Administrator Access

Needs Jira Administrator or Manage apps permission to install and configure the Forge app. Must access Jira Settings → Apps to set up and manage app connections.

Jira End-User Access

Requires Edit Issues and Add Comments permissions to view and use the Keeper panel Works across all Jira Cloud project types; no extra setup needed. See Jira Project Permissions for details

Keeper Standard Features

Requires an active Keeper Business, Enterprise, or PAM subscription with vault access.

Service account with permissions to create, update, and share records.

Endpoint Privilege Manager Features

  • Active KeeperPAM subscription

  • KEPM module enabled and configured in your Keeper environment

  • KEPM deployments, agents, and policies configured

  • For more information, see Endpoint Privilege Manager Overview

Keeper Security ITSM App

Required for EPM and SSO device admin approval workflows. The ITSM app owns webhook handling and Jira ticket creation, then adds ITSM_ labels that the Connector Hub detects to render approval panels.

Setup and Configuration

In order to communicate between the Jira service and Keeper, the customer is responsible for hosting a Keeper Commander Service Mode instance with an Ngrok or Cloudflare Tunnel. This can be accomplished many ways depending on your IT requirements. Commander Service Mode can run as a foreground service on any machine, or it can be run in a Docker container locally or remotely on a server.

Step 1. Commander Setup

Follow the setup steps documented in the Commander Service Mode REST API section to install Keeper Commander and start the service. You need to follow the instructions using either Ngrok or Cloudflare tunnels to properly route requests from the Forge app to your Commander instance. Commander Service Mode can run directly in the CLI, in the background on a local machine, on a remote server as a service, or under a Docker container. Using Docker is the recommended method.

Note the following Important Items:

1) The Request Queue System (API v2) must be enabled, e.g. -q=y

2) For Vault Management features, make sure the following commands are in the list:

3) For Vault + SSO Device Approval + KEPM features, make sure the following commands are in the list:

Command notes:

  • list-sf — required for Rotate-on-Expiration folder eligibility checks.

  • nsf-* — required for NSF (Nested Shared Subfolder) mode; omit them only for Classic-only deployments.

  • epm — required for KEPM approval panel actions and status checks.

  • device-approve — required for SSO device admin approval actions and pending checks.

4) For Ngrok Tunneling, ensure the following parameters are included:

5) For Cloudflare Tunneling, ensure the following parameters are included:

After service creation, the API key will be displayed in the console output. Make sure to copy and store it securely. If you are using Docker, you can pull the API key from the logs with this command:

When the Commander service is up and running, you should be able to submit a curl request to the endpoint. For example:

If the tunnel is running and the API key is correct, you should get a response like this:

Now that the service is up and running, move to the Jira configuration steps.


Step 2. Install the Keeper Forge App

Before configuring the integration, you must install the Keeper Forge app in your Jira Cloud instance.

See Forge App Installation Guide for detailed instructions.

Step 3. Jira Configuration

Configure the Integration in your Atlassian Jira instance as the Administrator.

  • In Jira: Go to Apps → Keeper.

  • Enter API URL including the /api/v2 path and API Key.

  • Example URLs:

    • Ngrok: https://your-subdomain.ngrok.io/api/v2

    • Cloudflare: https://your-subdomain.trycloudflare.com/api/v2

  • Test Connection

    • Click Test Connection → verify success.

  • Save Settings

Jira Admin configuration complete.


Step 4. ITSM Ticket Creation for EPM and Device Approvals

EPM and SSO device approval tickets are now created by the companion Keeper Security ITSM app. The Connector Hub no longer handles EPM webhook events or creates EPM tickets. The previous EPM webhook (web trigger) and ticket creation flow have been removed from the Forge app.

Configure the ITSM-driven approval flow:

  1. Install and configure the Keeper Security ITSM Integration in the same Jira instance

  2. In the ITSM app, configure the webhook URL and authentication token

  3. In the Keeper Admin Console > Reporting & Alerts > Alerts, configure alerts for:

    • Agent created approval request (EPM)

    • Changed approval request status (EPM)

    • Device admin approval requested (SSO device approval)

  4. Add the ITSM app's webhook URL and token as a recipient for these alerts

Keeper Admin Console - Webhook Configuration
  1. The ITSM app creates tickets with these labels:

  • ITSM_approval_request_created — EPM privilege elevation requests

  • ITSM_device_admin_approval_requested — SSO device approval requests

  1. The Connector Hub detects these labels on ITSM-created tickets and renders the appropriate admin panel


User Guide for Jira Workflow

  • Navigate to your Jira project (e.g., IT Support, Security Operations)

    • Create a new ticket.

  • Open a Jira Issue Page

    • On the right side panel, look for Keeper panel on the right.

    • The panel will load and display available Keeper actions.

    • Select action: Request Access to Record / Request Access to Folder / Request Record Permission Change.

    • Fill in form fields (required fields marked *).

  • Vault Mode

    • The panel defaults to NSF mode. Check "Use classic permission model" to switch to Classic mode. NSF uses a Role dropdown; Classic uses permission checkboxes — see Vault Modes and Permission Models.

  • Submit for Approval

    • First submission: Click Save Request to submit for admin approval.

    • Updating existing request: Click Update Request to modify your previously saved request.

    • A confirmation message will appear: "Request submitted successfully" or "Request updated successfully".

Action
When to Use

Grant or revoke access to individual records; use for time-bound access, temporary access, or team sharing.

Manage folder-level access and permissions for users or teams; useful for temporary project or contractor access.

Manage granular access to records within shared folders; enforce least-privilege and compliance.

Create New Secret (Admin Only)

Add new records to the Keeper vault; ideal for onboarding and provisioning new credentials.

Update Record (Admin Only)

Modify existing record fields such as passwords, usernames, URLs, or custom fields; for credential updates and password rotation.

Review and approve/deny privilege elevation requests from endpoints. Tickets are created by the ITSM app with ITSM_approval_request_created label.

Device Admin Approval (Admin Only)

Review and approve/deny SSO login device approval requests. Tickets are created by the ITSM app with ITSM_device_admin_approval_requested label.

Vault Modes and Permission Models

Sharing and permission actions support two vault modes. The panel defaults to NSF (Nested Shared Subfolder) mode; check "Use classic permission model" to switch to Classic mode. Records and folders display an NSF or Classic badge in the picker dropdown so you always know which model applies.The two modes express permissions differently:

  • NSF mode uses a single Role dropdown that bundles a set of permissions.

  • Classic mode uses individual permission checkboxes.

NSF roles

Role
Grants the user the ability to

Viewer

View content and participants

Share Manager

Manage share permissions, invite others, and approve requests

Content Manager

Manage content

Content and Share Manager

Manage content and manage share permissions

Full Manager

Edit, share, and manage ownership

Role rules: A Role is required when the action is grant. For revoke, the role is optional and acts as a filter. The role is ignored for folder remove actions and record owner (ownership transfer) actions.Classic permissionsIn Classic mode, each action exposes its own permission checkboxes instead of a role:

  • Request Access to Record: Allow Sharing, Allow Writing

  • Request Access to Folder: Can Manage Records, Can Manage Users, Can Share Records, Can Edit Records

  • Update Record Permissions in Folder: Can Share Records, Can Edit Records, Apply Recursively


Feature: Request Access to Record

Description: Request shared access to specific Keeper records

Capabilities:

  • Grant or revoke record access to users by email

  • Transfer record ownership

  • Set permissions based on vault mode:

    • NSF: select a Role (Viewer, Share Manager, Content Manager, Content and Share Manager, or Full Manager) — required when granting access

    • Classic: check Allow Sharing and/or Allow Writing

  • Configure access expiration (specific date/time or duration)

  • Apply permissions recursively to all records in a folder

  • Supports both NSF and Classic vault modes (see Vault Modes and Permission Models)

Request Access to Record

Feature: Request Access to Folder

Description: Request access to Keeper shared folders for users or teams.

Capabilities:

  • Grant or remove folder access (actions: grant / remove)

  • Assign to individual users or teams

  • Configure folder permissions based on vault mode:

    • NSF: select a Role (Viewer, Share Manager, Content Manager, Content and Share Manager, or Full Manager) — required when granting access

    • Classic: check any of Can Manage Records, Can Manage Users, Can Share Records, Can Edit Records

  • Set access expiration

  • Supports both NSF and Classic vault modes (see Vault Modes and Permission Models)

Request Access to Folder

Feature: Create New Secret

Description: Create new secret records directly in Keeper.

Capabilities:

  • Select from available record types (Login, Bank Account, SSH Key, etc.)

  • Fill in type-specific fields dynamically

  • Store secrets securely in Keeper vault

  • Supports both NSF and Classic vault modes

Admin-Only: Available to Jira Administrators and Project Administrators only

Create New Secret - Login type record

Feature: Update Record

Description: Update existing Keeper records.

Admin-Only: Available to Jira Administrators and Project Administrators only

Capabilities:

  • Search and select records from the vault

  • Modify record fields (title, login, password, URL, notes, etc.)

  • Force update option to override warnings

  • Supports both NSF and Classic vault modes

Note: You must have "Edit Issues" permission to see and use the Keeper panel.

Update Record

Feature: Manage KEPM Approval Requests

Description: Review, approve or deny Keeper Endpoint Privilege Manager (KEPM) requests directly in Jira.

EPM tickets are now created by the companion Jira ITSM app with the ITSM_approval_request_created label. The Connector Hub only detects this label and renders the EPM Approval Panel. The previous EPM webhook (web trigger) and ticket creation flow have been removed from the Forge app.

Capabilities:

  • Review outstanding requests with requester details, application name, and justification

  • Live countdown timer showing remaining time before request auto-expires (30-minute window)

  • Approve or deny elevation/command execution

  • Automatic detection if request was already processed outside Jira

KEPM Approval Request

Feature: Manage Device Admin Approval Requests

Description: Review, approve or deny SSO login device approval requests directly in Jira.

When a user logs in via SSO on a new device, the ITSM app creates a Jira ticket with the ITSM_device_admin_approval_requested label. The Connector Hub detects this label and renders the Device Approval Panel.

Capabilities:

  • View pending SSO device approval requests with requester email, device name, machine name, IP address, and client version

  • Approve or deny device registration via device-approve --approve / --deny commands

  • Automatic detection if request was already processed outside Jira (e.g., via Keeper Admin Console)

  • Device approvals do not auto-expire (unlike EPM requests)

SSO Device Approval

Feature: Rotate on Expiration (PAM Auto-Rotation)

Description: For eligible PAM credentials, automatically rotate the password the moment time-bound shared access expires — so a credential exposed for temporary access is never valid after the window closes.

How it appears: When you set an expiration on Request Access to Record or Request Access to Folder and the target is rotation-eligible, a "Rotate password upon expiration" checkbox appears. Enabling it adds the --rotate-on-expiration flag to the request.

Eligibility:

  • Record: the selected record must be of type pamUser.

  • Folder: the selected shared folder must be ROE-eligible (it contains rotation-eligible PAM records). The panel verifies this with list-sf <uid> --roe-eligible, so the list-sf command must be enabled in service-create.

The checkbox is hidden automatically for non-PAM records, non-eligible folders, and whenever no expiration is set.

Capabilities:

  • Auto-rotate a PAM password when shared access expires (no manual cleanup)

  • Works on both time-based expirations — Expire At (specific date/time) and Expire In (duration)

  • Supported in both NSF and Classic vault modes

  • Logged to the Jira issue: the action comment notes "Password will auto-rotate upon expiration"

Expiration required: Rotate on Expiration only works with a time-bound share. If you enable it without setting Expire At or Expire In, the request is rejected with "Expiration is required when rotate-on-expiration is enabled."

PAM configuration required: The target must be a fully configured PAM User record with rotation enabled. If rotation is not set up, the request fails with a configuration error. To resolve:

  • Verify the record is of type pamUser

  • Ensure rotation is enabled for that record (pam rotation edit)

  • Confirm a Keeper Gateway is active and connected

Troubleshooting

Debug Mode

If the Commander Service Mode REST API is not behaving as expected, enable debug mode for detailed logs and troubleshooting. For example:

Or (Docker):

When debug mode is enabled:

  • Console or Docker logs show detailed request/response traces

  • Useful for identifying configuration or API communication issues

  • Should be disabled in production to avoid exposing sensitive logs

Checking Service Status

  1. Check Service Mode Status via CLI keeper service-status

  2. Verify API Accessibility and Status

    • Test API endpoint and check service status:

    • Check if server is running and accessible from Jira

    • Verify firewall rules allow access

  3. Restart Service Mode

Note: EPM and SSO device approval tickets are created by the Jira ITSM app using webhook payload data, regardless of Commander Service Mode status. The Connector Hub does not create these tickets. Once Service Mode is available, the approval panels enrich ticket data with live status from the KEPM approval view and device-approve commands.

Troubleshooting Problems

Error / Symptom
Cause
Recommended Solution

Connection Failed / Timeout

Service Mode not running or tunnel not reachable

Verify the Service Mode instance is active and accessible. Ensure the Ngrok or Cloudflare tunnel is live and points to the correct port.

401 Unauthorized / 403 Forbidden

Invalid or expired API key

Retrieve the correct API key from Commander Service Mode logs and update it in the Jira configuration screen. Confirm no spaces or extra characters are included.

404 Not Found

Incorrect or incomplete API URL

404 Not Found | Incorrect or incomplete API URL | Use the complete API v2 URL including the /api/v2 path (e.g., https://xxxxx.ngrok.io/api/v2 or https://xxxxx.mycompany.com/api/v2). Ensure the tunnel forwards to the same port used by Service Mode.

502 Bad Gateway / 503 Service Unavailable

Service Mode offline or unresponsive

Restart the Service Mode instance and allow it to fully initialize. Review recent logs for configuration or authentication issues.

Actions Fail Despite Successful Connection

Missing commands or insufficient permissions

Confirm all required commands are enabled in Service Mode. Verify Keeper vault access permissions for the account executing the actions.

Feedback or feature requests? Please open an issue.

Last updated

Was this helpful?