The following sections provide an overview on creating custom plugins for One Identity Safeguard for Privileged Sessions (SPS) to authenticate your users to external services in addition to the authentication performed on the target server. For example, such plugins can implement two-factor authentication (2FA) or multi-factor authentication (MFA) methods, or request the user to provide a valid ticket ID for the connection. For details on using an existing plugin, see Integrating external authentication and authorization systems in the Administration Guide.
This document is a general overview of plugin requirements. If you want to write your own custom plugin, make sure to use the not officially supported Plugin SDK. For details, see: https://oneidentity.github.io/safeguard-sessions-plugin-sdk/latest/
|
|
Caution:
Using custom plugins in SPS is recommended only if you are familiar with both Python and SPS. Product support applies only to SPS: that is, until the entry point of the Python code and passing the specified arguments to the Python code. One Identity is not responsible for the quality, resource requirements, or any bugs in the Python code, nor any crashes, service outages, or any other damage caused by the improper use of this feature, unless explicitly stated in a contract with One Identity. If you want to create a custom plugin, contact our Support Team for details and instructions. |
Every SPS plugin is a Python module. SPS invokes the module to request the password of the target user. The plugin processes the request, returns the result to SPS and exits. SPS then processes the result.
The backup and restore functionality of SPS handles the uploaded plugins as part of SPS's configuration. You do not need to create separate backups of your plugins.
How the Authentication and Authorization plugin works
If a Connection Policy has an Authentication and Authorization plugin (AA plugin) configured, One Identity Safeguard for Privileged Sessions (SPS) runs the plugin as the last step of the connection authorization phase. SPS can request the client to perform other types of authentication before running the plugin. Using an AA plugin in a Connection Policy is treated as gateway authentication if:
-
the plugin authenticates the user
-
authentication is successful
-
the plugin returns the gateway_user and gateway_groups elements, identifying the user it has authenticated
Other types of gateway authentication will come before authentication by the AA plugin, so information from any other type of gateway authentication (for example, the username and usergroups of this authentication) will already be available and therefore can be used by the plugin. If the Authentication and Authorization plugin does perform gateway authentication, you can use a Credential Store as well.
However, for technical reasons, the web-based gateway authentication (that is, authenticating on the SPS web interface if the Require Gatweay Authentication on the SPS Web Interface option is selected in the Connection Policy) is performed after the AA plugin, so using AA plugin and ticking Require Gateway Authentication on the SPS Web Interface at the same time is not a valid configuration.
The plugin can interactively request additional information from the client in the SSH, Telnet, and RDP protocols.
NOTE: In SPS 5.8, a user's group membership is determined by querying only the relevant groups configured for the connection from the LDAP/AD server, instead of retrieving all groups of a given user.
This may cause problems when using AD/LDAP-based gateway authentication together with an AA plugin. The AA plugin authorize() hook may be called with only a subset of groups as group membership lookup does not consider groups referenced in the AA plugin code.
Consider that only groups queried by SPS are affected. Gateway groups returned by the AA plugin authenticate() hook are passed to the authorize() hook unchanged.
SPS runs the authorize method after the authentication method and any inband gateway authentication or inband destination selection steps. As a result, the authorize method already has access to the IP address of the target server and the remote username (the username used in the server-side connection).
Optionally, the plugin can return the gateway_user and gateway_groups values. SPS will only update the gateway username and gateway groups fields in the connection database if the plugin returns the gateway_user and gateway_groups values. The returned gateway_user and gateway_groups values override any such attributes already available on SPS about the connection (that means that channel policy evaluations will be affected), so make sure that the plugin uses the original values appropriately.
If the plugin returns the gateway_user and gateway_groups values, you may have to configure an appropriate Usermapping policy in the Connection Policy. If the plugin returns a gateway_user that is different from the remote user, the connection will fail without a usermapping policy. For details on usermapping policies, see Configuring usermapping policies in the Administration Guide.
Prerequisites
- SPS supports Authentication and Authorization plugins in the RDP, SSH, and TELNET protocols.
- In RDP, using an AA plugin together with Network Level Authentication in a Connection Policy has the same limitations as using Network Level Authentication without domain membership.
- In RDP, using an AA plugin requires TLS-encrypted RDP connections. For details, see Enabling TLS-encryption for RDP connections in the Administration Guide.
An SPS plugin is a .zip file that contains a MANIFEST file (with no extension) and a Python module named main.py in its root directory. The plugin .zip file may also contain an optional default.cfg file that serves to provide an example configuration, which you can use as a basis for customization if you wish to adapt the plugin to your site's needs. The size of the .zip file is limited to 20 megabytes.
You can invoke additional Python modules from main.py, provided that the total size of the .zip bundle does not exceed 20 megabytes and all calls are executed within the plugin timeout.
The modules must be compatible with the selected Python environment. For more information, see The available Python environments in the Creating Custom Authentication and Authorization Plugins.
