One Identity Safeguard for Privileged Sessions (SPS) provides a plugin framework to integrate SPS with external authentication and authorization systems, such as an external Credential Store, a ticketing system, or any third-party authentication or authorization solution.
Authenticating users to an external authentication and authorization system and the process overview that follows describe how user authentication works at a high level when there is an external authentication and authorization system involved:
Figure 6: Authenticating users to an external authentication and authorization system
-
The client tries to establish a connection to the target server.
-
SPS notices that an AA plugin is configured in the connection policy matching the connection. This is treated as gateway authentication. For details on gateway authentication, see The gateway authentication process.
-
SPS prompts the client for credentials.
-
The client provides authentication details to SPS when prompted.
-
SPS forwards the client's details to the external authentication and authorization system using the SPS API.
-
The external authentication and authorization system verifies the data received and provides feedback to SPS about the result.
-
If the client is granted access by the external authentication and authorization system, SPS authenticates the client to the target server, and establishes the connection.
For further information on plugins including configuration details, see Integrating ticketing systems and Integrating external authentication and authorization systems.
One Identity Safeguard for Privileged Sessions (SPS) can index the contents of audit trails, making the records of privileged users' activities easily searchable.
Audit trails contain user activity data recorded from terminal sessions (such as SSH and Telnet) and graphical protocols (such as RDP, Citrix ICA, and VNC). Examples of data recorded in audit trails are: mouse activity, keystrokes, and so on. Using its own indexer service or one or more external indexers, SPS determines elements of the content visible on the user's screen at a given point in time. Screen content elements include commands, window titles, IP addresses, user names, and so on.
The indexer generates the following types of output as a result of processing the audit trail files:
-
text
-
screenshot files
-
replayable video files
SPS then takes the output of indexing and breaks that down into searchable units.
Indexing audit trail files and the process overview that follows describe how indexing works at a high level:
Figure 7: Indexing audit trail files
-
SPS monitors and records the protocol traffic in the audited connections passing through SPS. Protocol traffic data is recorded in audit trail files.
-
Once a connection has been closed, SPS sends the audit trail files to the indexer.
-
The indexer parses the contents of the audit trail files, and builds an "inventory" of the privileged user's activity data based on what appeared on their screen.
In the case of a terminal session, screen content corresponds to the activity data that is captured in a terminal window. In the case of graphical protocols, screen content is whatever is visible in the graphical user interface of the applications the user is interacting with. In the latter case, the indexer's Optical Character Recognition (OCR) engine extracts text that appeared on the screen (for example, window titles).
-
The indexer returns the information extracted from the parsed audit trail files to SPS.
-
SPS processes the outcome of parsing and OCR-ing done in the previous phase and makes the data searchable.
-
Once indexed, the contents of the audit trails can be searched from SPS's web interface.
For details on how to configure SPS's internal indexer or one or more external indexers, see Indexing audit trails.
One Identity Safeguard for Privileged Sessions (SPS) supports the following protocols and clients. As a general rule, client applications not specifically tested, but conforming to the relevant protocol standards, should work with SPS. One Identity supports the listed client and server applications only on a best-effort basis after their vendor or manufacturer declares end-of-support or extended (or any other non-standard support) period for them. Best-effort basis means that without the vendor support we only can fix issues with our existing knowledge in the problematic area, and can implement straightforward fixes only.
Example
Microsoft provides mainstream and extended support periods for Windows Server 2012 Standard as described here. One Identity follows these periods and our best-effort support period starts at the same time when the mainstream period ends at Microsoft.
One Identity Safeguard for Privileged Sessions (SPS) supports the HTTP 1.0 and 1.1 standards.
