11.2 Central Credential Provider (CCP) & Web Service Integration

11.2 Central Credential Provider (CCP) & Web Service Integration

Quick Answer: The Central Credential Provider (CCP) is an agentless, centralized REST web service hosted on Microsoft Internet Information Services (IIS). It allows applications, cloud services, and automation scripts to retrieve Vault credentials over standard HTTPS (port 443) using HTTP GET requests (/AIMWebService/api/Accounts?AppID=...&Safe=...&Object=...) returning JSON or XML payloads. CCP is ideal for serverless architectures (AWS Lambda, Azure Functions), containerized microservices, and restricted appliances where installing a local agent is impossible. For enterprise resilience, multiple CCP instances are deployed behind a Network Load Balancer (NLB).

---

Agentless Secrets Management: The Central Credential Provider Concept

While the local Credential Provider (CP) delivers maximum performance and offline resilience, modern cloud and enterprise architectures frequently present environments where installing an OS-level agent is impractical or prohibited:

• Serverless Compute: Functions like AWS Lambda, Azure Functions, and Google Cloud Functions spin up and terminate within seconds, lacking persistent file systems or background daemon support to run local CP agents.
• Elastic Containers: In dynamic Kubernetes clusters scaling rapidly, deploying heavyweight OS agents to every node or container image introduces operational friction and image bloat.
• Restricted Appliances & Mainframes: Network firewalls, load balancers, and mainframes run proprietary firmware that prohibits third-party software installation.
• Cloud PaaS & SaaS Integrations: Enterprise platforms (Salesforce, ServiceNow, Azure App Services) communicate strictly via outbound web APIs and cannot host local agents.

CyberArk developed the Central Credential Provider (CCP) to address these environments by centralizing the retrieval interface on dedicated web servers.

---

Architectural Topology & Operational Mechanics

CCP is deployed on Windows Server running Microsoft Internet Information Services (IIS) and the .NET Framework. Architecturally, CCP is a web service application (AIMWebService) installed directly on top of a standard local Credential Provider on the same IIS host.

Operational Request Flow

1. Client Call: The client workload transmits an HTTPS GET request to the CCP web service URL.
2. IIS Processing & Authentication: IIS terminates the TLS connection, authenticates the client (via client certificate, Windows Integrated Authentication, or client IP address), and forwards parameters to the local provider via in-process .NET SDK calls.
3. Local Cache Evaluation: The underlying local CP on the IIS host evaluates the query. If the account is present in its local memory or disk cache, it fulfills the query in less than a millisecond without contacting the Digital Vault.
4. Vault Synchronization: If the account is not cached or requires synchronization, the local CP fetches the credential from the Vault over TCP port 1858.
5. Response Serialization: AIMWebService serializes the returned credential attributes into a JSON or XML payload and transmits an HTTP 200 response back to the client.

Because the local CP maintains its own cache, CCP minimizes Vault traffic, allowing a small CCP cluster to service thousands of clients.

---

REST Web Service API Syntax and Parameters

The CCP web service exposes a RESTful endpoint for programmatic secret retrieval:

Base Endpoint

GET /AIMWebService/api/Accounts?<Parameters> HTTP/1.1
Host: ccp.corp.internal
Accept: application/json

(Note: An alternative endpoint, /AIMWebService/v1.0/Accounts, is also supported for backwards compatibility).

Query Parameters

Practical Request Example

GET /AIMWebService/api/Accounts?AppID=BillingService&Safe=App_Billing_Safe&Object=OracleDB_Admin HTTP/1.1
Host: ccp.corp.internal
Accept: application/json

JSON Response Payload

Upon successful authentication and authorization, CCP returns an HTTP 200 OK status with a structured JSON response containing the plaintext secret in the Content field along with account metadata:

{
  "Content": "s3cureP@ssw0rd!2026",
  "PolicyID": "Oracle-Enterprise-DB",
  "UserName": "svc_pay",
  "Address": "10.20.30.40",
  "Safe": "Payments_Prod",
  "Name": "OracleDB_Admin",
  "DeviceType": "Database",
  "CreationDate": 1774051200,
  "LastModified": 1774094400
}

---

Authentication and Transport Security

Because CCP operates as a centralized web service, securing communication and strictly authenticating client requests is essential.

Transport Encryption

All CCP communication must be enforced over HTTPS (TLS 1.2 or TLS 1.3). Unencrypted HTTP (port 80) should be disabled in IIS to prevent cleartext credential interception on intermediate network segments.

Multi-Tier Authentication Options

CyberArk supports several authentication layers configured in the AppID definition:

1. Client Certificate Authentication (mTLS): Highest security standard for CCP. The client presents an X.509 certificate during TLS handshake. IIS validates certificate trust, and the Vault matches the certificate's Serial Number, Issuer, or SAN against AppID restrictions.
2. Client IP Address / Subnet Restriction: The AppID restricts requests to authorized client IP addresses or CIDR blocks (e.g., 10.150.20.0/24). Requests originating from unauthorized IPs are rejected with HTTP 401 Unauthorized.
3. Windows Integrated Authentication (Kerberos / NTLM): Used when calling clients reside within a trusted Active Directory domain, authenticating via domain service accounts.
4. Anonymous Authentication (Restricted): Permitted only when client certificate or domain authentication is unsupported, provided strict IP address filtering and AppID restrictions are enforced.

---

High Availability & Load Balancing Architecture

A single CCP server presents a single point of failure (SPOF). High availability and horizontal scalability are achieved by deploying multiple CCP servers behind a Network Load Balancer (NLB):

• Multi-Node Deployment: Deploy at least two independent Windows Server hosts running IIS and CCP across separate availability zones.
• Load Balancer Configuration: Configure stateless round-robin or least connections on an enterprise load balancer (e.g., F5 BIG-IP, AWS NLB). Because CCP requests are stateless GET calls, session stickiness is unnecessary.
• SSL Handling: If using mTLS, configure SSL Passthrough, or forward certificate details via headers (X-ARR-ClientCert) so IIS can inspect them.
• Health Monitoring: Monitor CCP health via periodic synthetic GET requests to /AIMWebService/api/Accounts to remove unhealthy nodes automatically.

---

Comparison: Credential Provider (CP) vs. Central Credential Provider (CCP)