One Identity Safeguard for Privileged Sessions 6.9.3 - REST API Reference Guide

Splunk integration

The universal SIEM forwarder can automatically send data about the audited sessions to Splunk, ArcSight, or other third-party systems. The messages are standard syslog messages in RFC3164 format (also called legacy-syslog or BSD-syslog format). The body of the syslog message (the MESSAGE part) can be formatted as JavaScript Object Notation (JSON), Common Event Format (CEF), or JSON-CIM format. For information about the details of the messages that the universal SIEM forwarder sends to the external SIEM network elements, see Message format forwarded to SIEMs.

One of the main advantages of the universal SIEM forwarder is that it has a lower impact on network and performance.

Each message contains the minimal information relevant to the event. Use the built-in correlation feature of the SIEM to combine events by session ID and view all information in one place.

GET https://<IP-address-of-SPS>/api/configuration/management/universal_siem_forwarder

Cookies

curl --cookie cookies https://<IP-address-of-SPS>/api/configuration/management/universal_siem_forwarder

{
    "body": {
        "enabled": true,
        "prefix": "myprefix",
        "targets": [
            {
                "format": "json_cim",
                "name": "siem_target",
                "protocol": {
                    "selection": "syslog",
                    "value": {
                        "address": {
                            "selection": "ip",
                            "value": "192.168.1.1"
                        },
                        "port": 5555,
                        "tls": {
                            "selection": "disabled"
                        }
                    }
                }
            }
        ]
     }

"protocol": {
    "selection": "syslog",
    "value": {
        "address": {
            "selection": "ip",
            "value": "192.168.1.1"
        },
        "port": 5555,
        "tls": {
            "selection": "secure",
            "trusted_ca_list_ref": "1241814345d074efd1ded7"
        }
    }
}

"address": {
    "selection": "ip",
    "value": "192.168.1.1"
},

"address": {
    "selection": "fqdn",
    "value": "my-siem.example.com"
},

tls": {
    "selection": "secure",
    "trusted_ca_list_ref": "1241814345d074efd1ded7"
}

"tls": {
    "selection": "disabled"
}

Manage Safeguard for Privileged Sessions clusters

When you have a set of two or more Safeguard for Privileged Sessions (SPS) instances in your deployment, you can join them into a cluster. This has several advantages. You can:

• Manage the nodes from one central location.

• Monitor their status and update their configuration centrally.

• Search all session data recorded by all nodes in the cluster on a single node.

• Scale the performance of the cluster by adding new nodes and joining them to the cluster easily.

• Extend auditing to other networks by adding new nodes to the cluster and joining them to the cluster.

This is achieved by assigning roles to the individual nodes in your cluster: you can set one of your SPS nodes to be the Central management node and the rest of the nodes are managed from this central node.

URL

GET https://<IP-address-of-any-node-in-cluster>/api/cluster

Cookies

Sample request

The following command lists the endpoints available under the cluster endpoint.

curl --cookie cookies https://<IP-address-of-any-node-in-cluster>/api/cluster

Response

The following is a sample response received.

For details of the meta object, see Message format.

{
    "items": [
        {
            "key": "configuration_sync",
            "meta": {
                "href": "/api/cluster/configuration_sync"
            }
        },
        {
            "key": "join_request",
            "meta": {
                "href": "/api/cluster/join_request"
            }
        },
        {
            "key": "nodes",
            "meta": {
                "href": "/api/cluster/nodes"
            }
        },
        {
            "key": "promote",
            "meta": {
                "href": "/api/cluster/promote"
            }
        },
        {
            "key": "status",
            "meta": {
                "href": "/api/cluster/status"
            }
        }
    ],
    "meta": {
        "href": "/api/cluster",
        "join_request": "/api/cluster/join_request",
        "nodes": "/api/cluster/nodes",
        "parent": "/api",
        "promote": "/api/cluster/promote",
        "status": "/api/cluster/status",
        "configuration_sync": "/api/cluster/configuration_sync"
    }
}

Status and error codes

The following table lists the typical status and error codes for this request. For a complete list of error codes, see Application level error codes.

Promote a Safeguard for Privileged Sessions node to be the Central Management node in a new cluster

You can build a cluster by promoting a Safeguard for Privileged Sessions node to the role of the Central Management node, and then join other nodes to your cluster.

To promote a node to be the Central Management node, complete the following steps:

1. Open a transaction.

   For details, see Open a transaction.

2. Create the Central Management node.

   POST an empty request to the https://<IP-address-of-node-to-become-Central-Management-node>/api/cluster/promote endpoint.

   The following is a sample response received.

   For details of the meta object, see Message format.

   {
       "body": {
           "address": "<IP-address-of-Central-Management-node>",
           "roles": [
               "central-management"
           ]
       },
       "meta": {
           "href": "/api/cluster/nodes/b35c54da-b556-4f91-ade5-d26283d68277",
           "parent": "/api/cluster/nodes",
           "remaining_seconds": 28800
       }
   }

   Elements		Type	Description
   body		Top-level element (JSON object)	Contains the JSON object of the node.
   	address	string	The IP address of the node.
   	roles	string	The role of the node.

3. Commit your changes.

   For details, see Commit a transaction.

Join node(s) to the cluster

Once you have a Central Management Safeguard for Privileged Sessions node in place, then you can join other nodes to your cluster.

To join nodes to your cluster, complete the following steps for each node that you want to join to the cluster:

1. Open a transaction.

   For details, see Open a transaction.

2. Create a join request.

   POST the IP address of the Central Management node as a JSON object to the https://<IP-address-of-node-to-join-to-cluster>/api/cluster/join_request endpoint. The body of the POST request should be the following:

   {
       "central_management_address": "<IP-address-of-Central-Management-node>"
   }

   For example:

   curl -X POST -H "Content-Type: application/json" --cookie cookies https://<IP-address-of-node-to-join-to-cluster>/api/cluster/join_request --data '{"central_management_address": "<IP-address-of-Central-Management-node>"}'

   The following is a sample response received.

   For details of the meta object, see Message format.

   By default, no role is assigned to a non-management node, that is why the "roles" array is empty.

   {
       "body": {
           "address": "<IP-address-of-node-joined-to-cluster>",
           "node_id": "46f97a58-4028-467d-9a22-9cfe78ae3e1c",
           "psk": "Ler7HZDFmZCxnLLgHNRfZYfORhlZS99l9vEVr5UKtJEb1d4WeaHcBmQJLs4VDWIn",
           "roles": []
       },
       "meta": {
           "href": "/api/cluster/join_request",
           "parent": "/api/cluster",
           "remaining_seconds": 600
       }
   }

   Elements		Type	Description
   body		Top-level element (JSON object)	Contains the JSON object of the node.
   	address	string	The IP address of the node.
   	node_id	string	A reference ID for the node.
   	psk	string	The pre-shared key of the node used for authentication.
   	roles	string	The role of the node.

3. Join the node to the cluster.

   POST the "body" object of the response to the https://<IP-address-of-Central-Management-node>/api/cluster/nodes endpoint as a JSON object. The body of the POST request should be the following:

   {
       "address": "<IP-address-of-node-joined-to-cluster>",
       "node_id": "46f97a58-4028-467d-9a22-9cfe78ae3e1c",
       "psk": "Ler7HZDFmZCxnLLgHNRfZYfORhlZS99l9vEVr5UKtJEb1d4WeaHcBmQJLs4VDWIn",
       "roles": []
   },

   For example:

   POST -H "Content-Type: application/json" --cookie cookies https://<IP-address-of-Central-Management-node>/api/cluster/nodes --data '{"address": "<IP-address-of-node-joined-to-cluster>", "node_id": "46f97a58-4028-467d-9a22-9cfe78ae3e1c", "psk": "Ler7HZDFmZCxnLLgHNRfZYfORhlZS99l9vEVr5UKtJEb1d4WeaHcBmQJLs4VDWIn","roles": []}'

   If the POST request is successful, the response includes:

   {
       "body": {
           "address": "<IP-address-of-node-joined-to-cluster>",
           "roles": []
       },
       "key": "46f97a58-4028-467d-9a22-9cfe78ae3e1c",
       "meta": {
           "href": "/api/cluster/nodes/46f97a58-4028-467d-9a22-9cfe78ae3e1c",
           "parent": "/api/cluster/nodes",
           "remaining_seconds": 28800
       }
   }

4. Commit your changes on both the Central Management node and the node you joined to the cluster.

   For details, see Commit a transaction.