Tchater maintenant avec le support
Tchattez avec un ingénieur du support

One Identity Safeguard for Privileged Sessions 6.0.11 - Creating custom Authentication and Authorization plugins

Tips and tricks

If you need the public hostname of SPS in the plugin, the plugin can read it from the /etc/hostnickname file.

The sample configuration file (default.cfg)

Your plugin .zip file may contain an optional default.cfg sample configuration file. This file serves to provide an example configuration that you can use as a basis for customization if you wish to adapt the plugin to your site's needs.

The only prerequisites for this file are as follows:

  • It must be a UTF-8 encoded text file.
  • The size of the file must not exceed 10 KiB.

Other than these prerequisites, the contents of the file are not restricted in any way.

Plugin troubleshooting

On the default log level, One Identity Safeguard for Privileged Sessions (SPS) logs everything that the plugin writes to stdout and stderr. Log message lines are prefixed with the session ID of the proxy, which makes it easier to find correlating messages.

To transfer information between the methods of a plugin (for example, to include data in a log message when the session is closed), you can use a cookie.

If an error occurs while executing the plugin, SPS automatically terminates the session.

NOTE:

This error is not visible in the verdict of the session. To find out why the session was terminated, you have to check the logs.

Integrating SPS to ticketing systems

From SPS 5 LTS and later, this functionality is available using the Authentication and Authorization (AA) plugin.SPS executes the authorize method after the authentication method, and any inband gateway authentication or inband destination selection selection steps. As a result, the authorize method already has access the IP address of the target server, and the remote username (that is, the username used in the server-side connection).

To use an AA plugin to integrate SPS to a ticketing system, note the following points.

  • You can only request the ticket ID or other information from the user in the authentication hook (authenticate). For details on how the user can provide such data during a connection, see "Integrating external authentication and authorization systems" in the Administration Guide.
  • You must implement the actual authorization (for example, connecting and querying the ticketing system) in authorize. As a side effect, if the user submits an invalid ticket ID (or other invalid information) in the authentication hook, this error will not be recognized until the authorization hook. The user cannot correct this error and SPS will reject the connection. In this case, the user must initiate a new connection to provide the correct information.
  • Only the Remote Desktop (RDP), Secure Shell (SSH), and Telnet protocols are supported.
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation