Zscaler package v1.0.0

A ZIA API session cookie, held in the client's own secret manager. The stored material must be the complete Cookie header value: 'JSESSIONID=' followed by the session id returned by the ZIA authenticatedSession call — the raw path (POST /api/v1/authenticatedSession) and the cookie name (JSESSIONID, returned in the Set-Cookie header) are printed verbatim in Zscaler's official API Authentication specification and Getting Started article on help.zscaler.com (retrieved 2026-09-23). ZIA's legacy authentication is a derived session, not a static token: an external deployment process POSTs a JSON body containing an API-enabled admin's username, password and the tenant API key — obfuscated with Zscaler's documented timestamp-based obfuscation, which is obfuscation, not encryption — to /api/v1/authenticatedSession on the customer's ZIA cloud host, and stores the resulting session cookie under this reference.

The three source values (username, password, API key) are separate secrets under their own vault references; the executor injects the stored cookie verbatim and performs no session lifecycle itself, so renewal ownership sits entirely with that external process. Zscaler documents a default JSESSIONID lifetime of 5 minutes and invalidation by an explicit logout (DELETE /authenticatedSession); calls made after expiry or logout fail closed with a 401.

Rotating the API key or disabling the admin stops NEW session issuance, but an already-established session should be treated as valid until it expires or is logged out — stopping issuance is not session invalidation, so on suspicion the custody job must explicitly log out the session, not only rotate the key.

Least privilege: use a dedicated API-only admin whose role permits exactly the registered scope (read-only administration for the reads; URL filtering configuration only where rule creation and activation are enabled), and never a full admin. The ZPA capabilities in this pack override this credential block with their own bearer-token reference (see their inject fields). ZPA legacy authentication is OAuth2 client credentials, verified against Zscaler's ZPA API Getting Started and About API Key Management articles (help.zscaler.com, retrieved 2026-09-23): client_id and client_secret are issued on the ZPA console's API Keys page (Administration > API > Private Access API; earlier SDK documentation named the older Configuration & Control > Public API > API Keys path), the client secret is displayed only when the key is first created, the customer id identifies the tenant and is copyable from the API Keys page menu, and the ZPA cloud value selects the API gateway; the external custody job exchanges the client credentials for an access token at the tenant's ZPA gateway (POST /signin with form-encoded client_id and client_secret, returning token_type Bearer) and stores the complete 'Bearer <token>' Authorization header value.

The retrieved documentation sets the token's default lifetime at 3,600 seconds (one hour); it still does not state whether deleting the API key invalidates already-issued tokens — treat any captured token as live until expiry.

Least privilege: a dedicated API key whose console role permits exactly the registered application-segment read/create scope, never a full admin.

Executor hygiene: the cookie and the bearer value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint hosts 'zscaler-zia.invalid' and 'zscaler-zpa.invalid' are reserved non-production placeholders (an RFC 2606 reserved TLD): substitute the customer's own ZIA cloud API host (zsapi.<cloud name> for the tenant's cloud) and ZPA gateway host before enabling, in every endpoint, in the resource locators and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step.

This pack registers the legacy ZIA session model: ZIA API authentication is a session-cookie flow in which the client POSTs an admin username, password and the tenant's obfuscated API key to /api/v1/authenticatedSession and receives a session cookie; the stored credential is the resulting cookie value, minted and refreshed by an external custody job — see the credential note. ZIA configuration changes are staged per session and only take enforcement effect when activated: zia.config.activate applies ALL staged changes tenant-wide — including changes staged by other sessions and by console users — and is registered with the deploy action at the minimum R3 tier.

The ZPA capabilities override the pack credential: ZPA's API uses OAuth2 client-credentials bearer tokens, not the ZIA session cookie, so the ZPA capabilities name a separate reference and the Authorization header. Zscaler's newer Zidentity OneAPI framework (a single OAuth2 client across ZIA/ZPA) exists and is preferred by the vendor for migrated tenants; the retrieved vendor SDK documentation shows OneAPI is NOT only a credential change: it moves authentication to the Zidentity token endpoint (https://<vanity_domain>.zslogin.net/oauth2/v1/token) and serves the products from a different API base authority (api.<cloud_name>.zsapi.net) with its own path contract, so a migrated tenant must re-review authority, paths and credential wiring together rather than swapping only the credential reference.

Documentation basis: raw endpoint paths and methods are verified against Zscaler's official per-product Swagger/OpenAPI specifications served from help.zscaler.com (retrieved 2026-09-23): the ZIA API Authentication, URL Categories, URL Filtering Policy, Firewall Policies and Activation specifications (host zsapi.[zscaler-cloud-name], basePath /api/v1) and the ZPA Application Segment Management specification (OpenAPI 3.0.0) print every path and method this pack registers. The help site's HTML pages render client-side, but its JSON content API (help.zscaler.com/zapi/fetch-data) exposes each API section's downloadable specification file; the vendor-maintained Python SDK documentation listed in sources corroborated the operation surface in the first phase and remains listed.

Documented exclusions — this pack does not register: any DELETE endpoint (URL filtering rule, firewall rule, URL category or application segment deletion — removing an enforcement rule can silently reopen blocked traffic, and deletion is not part of this pack), admin user, role and API-key management, PAC file management, ZPA connector provisioning or deletion, sandbox file submission (which sends customer files for analysis), sublocation and location VPN credential management, and ZIA DLP dictionary/policy management.