OpenText ArcSight User Management API Guide

Auth method: Bearer token (session-based login token obtained via /auth/login endpoint; OAuth 2.0 not explicitly documented for user-management REST API)

Setup steps

1. POST credentials to /platform-service/rest/v1/auth/login with username and password in the request body to receive a session token.
2. Include the returned token in subsequent requests as an Authorization: Bearer header.
3. For SCIM provisioning, generate a SCIM bearer token from the ArcSight Platform Admin UI under User Management > SCIM Configuration.
4. Tokens are scoped to the tenant; ensure the account used has the System Admin role for user-management operations.

List Users (SCIM)

• Method: GET
• URL: https://<host>/platform-service/scim/v2/Users
• Watch out for: SCIM token must be generated from the Platform Admin UI; it is separate from the REST API session token.

Request example

GET /platform-service/scim/v2/Users?startIndex=1&count=20
Authorization: Bearer <scim-token>

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 50,
  "startIndex": 1,
  "itemsPerPage": 20,
  "Resources": [{"id":"abc123","userName":"jdoe"}]
}

Get User by ID (SCIM)

• Method: GET
• URL: https://<host>/platform-service/scim/v2/Users/{id}
• Watch out for: The id value is server-assigned; use the id from the ListResponse, not the externalId.

Request example

GET /platform-service/scim/v2/Users/abc123
Authorization: Bearer <scim-token>

Response example

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "abc123",
  "userName": "jdoe",
  "active": true,
  "emails": [{"value":"jdoe@example.com","primary":true}]
}

Create User (SCIM)

• Method: POST
• URL: https://<host>/platform-service/scim/v2/Users
• Watch out for: User must be assigned a role within ArcSight Platform separately; SCIM creation alone does not grant product access.

Request example

POST /platform-service/scim/v2/Users
Authorization: Bearer <scim-token>
Content-Type: application/scim+json
{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName":"jdoe",
  "emails":[{"value":"jdoe@example.com","primary":true}],
  "active":true
}

Response example

HTTP 201 Created
{
  "id": "abc123",
  "userName": "jdoe",
  "active": true
}

Update User (SCIM PATCH)

• Method: PATCH
• URL: https://<host>/platform-service/scim/v2/Users/{id}
• Watch out for: PATCH is the preferred method for deactivation; DELETE may permanently remove the user record.

Request example

PATCH /platform-service/scim/v2/Users/abc123
Authorization: Bearer <scim-token>
Content-Type: application/scim+json
{
  "schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations":[{"op":"replace","path":"active","value":false}]
}

Response example

HTTP 200 OK
{
  "id": "abc123",
  "userName": "jdoe",
  "active": false
}

Replace User (SCIM PUT)

• Method: PUT
• URL: https://<host>/platform-service/scim/v2/Users/{id}
• Watch out for: PUT replaces the entire user object; omitting optional fields may clear existing values.

Request example

PUT /platform-service/scim/v2/Users/abc123
Authorization: Bearer <scim-token>
Content-Type: application/scim+json
{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName":"jdoe",
  "displayName":"John Doe",
  "active":true
}

Response example

HTTP 200 OK
{
  "id": "abc123",
  "userName": "jdoe",
  "displayName": "John Doe"
}

Delete User (SCIM)

• Method: DELETE
• URL: https://<host>/platform-service/scim/v2/Users/{id}
• Watch out for: Deletion is permanent. Consider PATCH active=false for reversible deprovisioning.

Request example

DELETE /platform-service/scim/v2/Users/abc123
Authorization: Bearer <scim-token>

Response example

HTTP 204 No Content

List Groups (SCIM)

• Method: GET
• URL: https://<host>/platform-service/scim/v2/Groups
• Watch out for: Groups in ArcSight Platform correspond to user groups used for role-based access; group names must match existing platform groups.

Request example

GET /platform-service/scim/v2/Groups?startIndex=1&count=20
Authorization: Bearer <scim-token>

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 5,
  "Resources": [{"id":"grp1","displayName":"Analysts"}]
}

Authenticate / Get Session Token (REST API)

• Method: POST
• URL: https://<host>/platform-service/rest/v1/auth/login
• Watch out for: Session tokens expire; re-authenticate or implement token refresh logic. Token lifetime is not explicitly documented.

Request example

POST /platform-service/rest/v1/auth/login
Content-Type: application/json
{
  "login": "admin",
  "password": "<password>"
}

Response example

HTTP 200 OK
{
  "token": "<session-token>",
  "tokenType": "Bearer"
}

• Rate limits: No explicit rate-limit documentation found in official ArcSight Platform or ESM REST API docs.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: Rate limits are not publicly documented. Behavior may be governed by underlying infrastructure (e.g., reverse proxy or load balancer) rather than application-level throttling.

• Pagination method: offset

• Default page size: 0

• Max page size: 0

• Pagination pointer: startIndex and count (SCIM standard parameters); REST API pagination parameters not explicitly documented

• Webhooks available: No

• Webhook notes: ArcSight Platform and ESM do not document outbound webhook support for user-management events in official documentation.

• Alternative event strategy: Use ArcSight's event correlation and forwarding rules to push security events to external systems; for user lifecycle events, poll the SCIM /Users endpoint or rely on IdP-side event notifications.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https:///platform-service/scim/v2

• Supported operations: GET /Users (list), GET /Users/{id}, POST /Users (create), PUT /Users/{id} (replace), PATCH /Users/{id} (update/deactivate), DELETE /Users/{id}, GET /Groups (list), GET /Groups/{id}, PATCH /Groups/{id} (add/remove members)

Limitations:

• SCIM token is generated manually from the Platform Admin UI; no automated token rotation API is documented.
• Role assignment via SCIM may require ArcSight-specific schema extensions not fully documented publicly.
• SCIM provisioning is available in ArcSight Platform (cloud/on-prem unified platform); availability in standalone ESM on-premises deployments is not confirmed in official docs.
• No documented support for SCIM /ServiceProviderConfig or /Schemas discovery endpoints.
• Group membership changes via SCIM may not immediately propagate to all ArcSight product modules.

Three primary automation scenarios are supported by the SCIM 2.0 API.

Provision a new analyst: POST to /platform-service/scim/v2/Users with userName, emails, and active:true.

Capture the server-assigned id from the 201 response.

SCIM user creation does not automatically assign ArcSight product roles;

a separate role-assignment step via the Platform Admin UI or REST API is required before the user can access ArcSight consoles.

Deactivate without destroying audit trail: PATCH /platform-service/scim/v2/Users/{id} with {op:replace, path:active, value:false}.

Prefer this over DELETE - deletion is permanent and removes the user record, which can break audit log attribution and compliance reporting.

Confirm deactivation by verifying active:false in a subsequent GET response.

Bulk access review: Paginate GET /platform-service/scim/v2/Users?startIndex=1&count=100.

Check totalResults in the ListResponse and iterate by incrementing startIndex by count until all pages are retrieved.

Default and maximum page sizes are not explicitly documented;

test with count=100 and reduce if the server returns errors or truncated responses.

Provision a new analyst user via SCIM

1. Generate a SCIM bearer token from ArcSight Platform Admin UI > User Management > SCIM Configuration.
2. POST to /platform-service/scim/v2/Users with userName, emails, and active:true in the request body.
3. Capture the server-assigned id from the 201 response.
4. If role assignment is not handled by SCIM, log in to the Platform Admin UI or use the REST API to assign the appropriate ArcSight role (e.g., Analyst) to the new user.

Watch out for: SCIM user creation does not automatically assign ArcSight product roles; a separate role-assignment step may be required before the user can access ArcSight consoles.

Deactivate a departing user without deleting their audit trail

1. Retrieve the user's SCIM id via GET /platform-service/scim/v2/Users?filter=userName eq "jdoe".
2. PATCH /platform-service/scim/v2/Users/{id} with Operations: [{op:replace, path:active, value:false}].
3. Verify the user can no longer authenticate by checking active:false in the GET /Users/{id} response.

Watch out for: Using DELETE instead of PATCH active=false permanently removes the user record, which may affect audit log attribution and compliance reporting.

Bulk-list all users for access review

1. GET /platform-service/scim/v2/Users?startIndex=1&count=100 with the SCIM bearer token.
2. Check totalResults in the ListResponse; if greater than count, iterate by incrementing startIndex by count until all pages are retrieved.
3. Extract userName, active, emails, and groups fields from each Resource for the access review report.

Watch out for: Default and maximum page sizes are not explicitly documented; test with count=100 and reduce if the server returns errors or truncated responses.

The most consequential integration trap is assuming SCIM provisioning fully manages access. SCIM user creation provisions the account but does not assign ArcSight product roles; without a separate role-assignment step, a provisioned user has no effective access to ArcSight consoles.

Role assignments may require ArcSight-specific SCIM schema extensions that are not fully documented publicly, or a fallback to UI-based configuration.

A second trap is token confusion. The SCIM bearer token and the REST API session token are generated through different mechanisms and are not interchangeable. Using the wrong token against an endpoint will result in authentication failures that are not always clearly surfaced in error responses.

Rate limits are not publicly documented for either the SCIM or REST API surfaces. Behavior is likely governed by underlying infrastructure rather than application-level throttling, meaning limits may vary by deployment and will not be signaled by standard rate-limit headers. Build in conservative retry logic with exponential backoff.

Additionally, SCIM availability in standalone ESM on-premises deployments is not confirmed in official documentation; verify endpoint availability in your specific deployment before building automation dependencies against it.