11.3 Application Server Credential Provider (ASCP) & Application Authentication (AppID)

11.3 Application Server Credential Provider (ASCP) & Application Authentication (AppID)

Quick Answer: The Application Server Credential Provider (ASCP) eliminates hardcoded database credentials from enterprise Java application servers (IBM WebSphere, Oracle WebLogic, Red Hat JBoss/WildFly, and Apache Tomcat) by deploying CyberArk JDBC driver wrappers. These wrappers intercept DataSource connection requests and fetch credentials dynamically from the local Credential Provider without modifying application source code. To prevent unauthorized processes from impersonating applications, the Digital Vault enforces the AppID Authentication Framework, a multi-layered defense-in-depth model verifying OS User, Executable Path, Cryptographic Hash (SHA-256), and IP/Machine Address.

---

Application Server Credential Provider (ASCP) & Dynamic JDBC Data Sources

In enterprise Java EE environments, application servers manage database connectivity through DataSources and connection pools. Historically, configuring DataSources required defining credentials in static XML files:

• Apache Tomcat: conf/context.xml or conf/server.xml
• Red Hat JBoss / WildFly: standalone/configuration/standalone.xml
• IBM WebSphere Application Server: resources.xml
• Oracle WebLogic Server: config/jdbc/datasource-name.xml

Even when obfuscated or hashed, underlying keys were stored in server binaries, making them reversible. Additionally, rotating database passwords required manual XML edits and restarting server JVM clusters, causing service downtime.

The ASCP Integration Model

CyberArk introduced the Application Server Credential Provider (ASCP) to resolve this problem:

1. JDBC Driver Interception: ASCP deploys a lightweight CyberArk JDBC driver wrapper (e.g., CyberArk.jdbc.driver.CyberArkDriver) into the application server's shared library classpath, wrapping native database drivers (Oracle, SQL Server, DB2, PostgreSQL, MySQL).
2. Zero Code Modifications: Applications issue standard java.sql.DataSource.getConnection() calls without code changes. Administrators simply update the DataSource driver class name and append CyberArk parameters (AppID, Safe, Object) to the JDBC connection URL.
3. Dynamic Retrieval: When the application server initializes connection pools, the wrapper queries the local Credential Provider, retrieves the database password from local cache in sub-millisecond time, and establishes the database connection.
4. Rotation Without Restarts: When CPM rotates database passwords, the new credential synchronizes to the local CP cache. Stale connections are refreshed automatically from cache, renewing the pool without JVM restarts.

---

The Application ID (AppID) Governance Framework

Programmatic consumers cannot use human interactive authentication. Instead, every non-human workload is represented in the Vault by an Application ID (AppID).

Defining an AppID in the Vault

Administrators configure AppIDs in the PVWA under Applications -> Add Application:

• Application Name (AppID): Unique string identifying the workload (e.g., BillingService_Prod).
• Description & Business Owner: Governance metadata for compliance audits.
• Safe Membership & Permissions: An AppID cannot access credentials until granted explicit permissions on target Safes:
  • Retrieve accounts: Mandatory; allows reading secret payloads.
  • List accounts: Mandatory; allows discovering objects in the Safe.

The Impersonation Threat Model

If security relied solely on knowing the AppID string, an attacker gaining shell access to a server could execute clipasswordsdk -p AppID=BillingService_Prod to steal credentials. CyberArk eliminates this risk through Application Authentication Restrictions.

---

Multi-Layered Authentication Restrictions (Defense-in-Depth)

CyberArk enforces a multi-layered verification model directly in the AppID properties, verifying multiple independent criteria before releasing credentials:

1. Operating System User Verification

• Mechanism: Restricts credential retrieval to processes running under specific operating system accounts (e.g., tomcat_svc, DOMAIN\svc_billing).
• Enforcement: The CP inspects the primary process security token via GetTokenInformation on Windows, or the effective User ID (euid) from /proc on Linux.
• Protection: Unauthorized users or administrators running clipasswordsdk interactively are rejected with APPAP002E Authentication error: OS user verification failed.

2. Executable Path Restriction

• Mechanism: Restricts queries to binaries or scripts running from exact absolute file paths (e.g., /usr/local/tomcat/bin/catalina.sh, C:\Program Files\Apache Tomcat\bin\tomcat9.exe).
• Protection: Prevents attackers from copying authorized script names to unauthorized directories (e.g., /tmp/exploit.sh) to invoke the AppID.

3. Cryptographic Hash (SHA-256) Verification

• Mechanism: Administrators register the cryptographic SHA-256 hash of the authorized binary or script in the AppID.
• Enforcement: The CP agent computes the SHA-256 hash of the calling executable on disk and verifies it against the registered hash before releasing secrets.
• Protection: Modifying even a single byte of an authorized binary changes its SHA-256 hash, causing immediate request rejection. This prevents binary replacement, Trojan insertions, and script tampering.

4. IP Address and Subnet Restriction

• Mechanism: Restricts requests to specific IPv4/IPv6 addresses, subnet CIDR blocks (e.g., 10.100.50.0/24), or DNS hostnames.
• Protection: Blocks requests replaying authorized AppID parameters from foreign network segments.

5. Client Certificate Serial Number & Issuer (For CCP / REST)

• Mechanism: Validates X.509 client certificates presented during mutual TLS (mTLS) against registered certificate serial numbers, issuers, or Subject Alternative Names (SAN).

---

CI/CD Hash Automation & Common Error Codes

Managing Hashes in Automated CI/CD Pipelines

Because compiling a new binary alters its SHA-256 hash, release pipelines automate hash updates using the PVWA REST API:

POST /PasswordVault/API/Applications/{AppID}/Authentications HTTP/1.1
Host: pvwa.corp.internal
Content-Type: application/json
Authorization: <SessionToken>

{
  "AuthType": "Hash",
  "AuthValue": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "IsFolder": false
}

The build pipeline calculates the binary's hash during compilation and calls the PVWA API to register it before restarting the application service.

Troubleshooting Common AppID Error Codes