Chat now with support
Chat with Support

One Identity Safeguard for Privileged Sessions 5.8.0 - Administration Guide

Preface Introduction The concepts of SPS The Welcome Wizard and the first login Basic settings User management and access control Managing SPS
Controlling SPS: reboot, shutdown Managing Safeguard for Privileged Sessions clusters Managing a high availability SPS cluster Upgrading SPS Managing the SPS license Accessing the SPS console Sealed mode Out-of-band management of SPS Managing the certificates used on SPS
General connection settings HTTP-specific settings ICA-specific settings RDP-specific settings SSH-specific settings Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search (classic) interface Using the Search interface Searching session data on a central node in a cluster Advanced authentication and authorization techniques Reports The SPS RPC API The SPS REST API SPS scenarios Troubleshooting SPS Configuring external devices Using SCP with agent-forwarding Security checklist for configuring SPS Jumplists for in-product help Third-party contributions About us

RPC client requirements

The client application used to access SPS must meet the following criteria:

  • Support SOAP version 1.1 or later.

  • Support WSDL version 1.1.

  • Properly handle complex object types.

  • Include a JSON decoder for interpreting the results of search operations.

The following client libraries have been tested with SPS.

Table 28: SOAP libraries tested with SPS
Client name Programming language Status Comments
Apache Axis 1 Java Working
Built-in .NET library .NET Working

SPS does not support the Expect HTTP Header feature, and must be disabled, for example, using System.Net.ServicePointManager.Expect100Continue = false;

Scio Python Partially working Does not handle complex object types, so it cannot perform search queries.
SOAP::Lite Perl Working
  • Simple types can be used with the following format: $service->$method(@params)

  • Complex types work only with the following format: $service->call($method, @params)

  • Calls using the $service->call() format seem to work after doing at least one $service->$method(@params) call, for example, a login.

SOAP::WSDL Perl Not working
Suds Python Working

Locking SPS configuration from the RPC API

Accessing SPS using the RPC API locks certain components of SPS from other users, just like accessing SPS using the web interface or the console. Locking SPS via RPC can be performed either explicitly by calling the lockAcquire function, or implicitly when an operation requires the lock. In either case, ensure that your application verifies that the lock is received and properly handles if the component is locked by someone else (for example, because a user is accessing the component from the web interface).

For details on how locking works in SPS, see "Multiple users and locking" in the Administration Guide.

Documentation of the RPC API

The documentation of the SPS RPC API is available online from the SPS web interface: select Basic Settings > Management > RPC API settings > Open documentation, or directly from the following URL: https://<ip-address-of-SPS>/rpc-api-doc/. This documentation contains the detailed description of the available services and classes.

Enabling RPC API access to SPS


To configure SPS to accept RPC API connections, complete the following steps.

  1. Log in to the SPS web interface.

  2. Select Basic Settings > Management > RPC API settings > Enable RPC API.

    Figure 263: Basic Settings > Management > RPC API settings — Enabling RPC API access to SPS

  3. Click Commit.

    Expected result:

    Users accounts belonging to a usergroup that have read and write/perform rights to the Access RPC API privilege can access SPS via the RPC API.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating