Scripting supports the use of external Identity Providers (IdPs) to authenticate user login to Scripting via SAML 2.0, in a process known as Single Sign On (SSO).
If you wish to make use of the Single Sign On feature, please contact your Scripting vendor.
Configuring SSO within Scripting is a simple process:
-
Ensure that the
Accepted Origins option within the Security section will allow communication from any Identity Provider(s) that will be configured - either as the default of
*, or by explicitly listing the originating hostname(s) that the Identity Provider(s) will use to send authentication responses from. Failure to do this will lead to an error when trying to log in using SSO due to "Unrecognised Origin".
-
Ensure that the
Single Sign On Only option within the Security section is disabled (while completing configuration). Failure to do this could lead to losing the ability to log in to your Scripting system should there not be any valid SSO connectors active.
-
Once these preparatory steps have been completed, configure a
SSO (Generic Provider) connector for any Identity Provider(s) to be used to authenticate SSO requests, and ensure that the connector is set to be active.
-
Ensure that any user(s) that will be utilising SSO have their usernames set to match the identifier returned by the Identity Provider(s).
-
At this point, if desired the
Single Sign On Only option within the Security section can be enabled. In all cases, before doing so it should be ensured that at least one user with the System Manager licence assigned to them can access the system via SSO.
Once this has been completed, then any active SSO connectors will be visible on the
login page.
Known and Supported Identity Providers
The Identity Providers listed in the table below have been tested with Scripting, and it is expected that most providers will work given the generic nature of the SAML communication.
|
Identity Provider
|
Notes
|
|
Azure Active Directory
|
You will need to acquire the requisite pieces of information from an application in your Azure Active Directory. Details surrounding the configuration of a SAML SSO application can be found in this article. |
|
Active Directory Federated Services
|
As ADFS is deployable in a number of different configurations, you will need to refer to the appropriate Microsoft documentation for your implementation.
|
|
Okta SSO
|
Please refer to Okta documentation for configuration steps. Be aware that the Identifier (Entity ID) within the connector configuration will be the value that you specified during app creation within Okta as the Audience URI (SP Entity ID).
|
Other providers also may work with Scripting. If you wish to have a different Identity Provider verified, please contact your Scripting vendor.
Single Sign On will be available to all users when a configured connector is activated, as long as their username matches the detail returned by that Identity Provider from a successful authentication request.
Unless the
Single Sign On Only option is enabled, then users will still be able to log in directly via their Scripting username and password. As such, care should still be taken to ensure that secure passwords are configured for users. If the desire is to only allow certain users to login via their Scripting username and password (e.g. a master admin account), then it's recommended that all other users have passwords assigned to them that are unknown to the user themself.
If the
Single Sign On Only option is enabled, then extra care should be taken to ensure that the configured connectors remain valid and aren't allowed to expire or similar. In the event that no configured connectors have valid details (but at least one connector is still enabled), a database intervention will be necessary to set the value of the
Single Sign On Only key within
tbl_AppConfig to
false and then recycle the website's Application Pool to bring the new setting into cache.
It is possible to pre-select an SSO provider for users by including the
sso URL parameter with the (case insensitive) name of a connector (e.g.
https://examplesite.com/login.aspx?sso=azure). This will immediately direct the user to the IdP configured for the named connector upon loading the page, and can also be used to
URL pop scripts.
Single Sign On can be configured with other systems that support SSO to avoid the need for the user to log in repeatedly. For instance, if Scripting is embedded within another application's frame (such as
Genesys Cloud) that is also making use of SSO to authenticate users, then configuring a connector using the same Identity Provider and including the appropriate
sso URL parameter in the Scripting URL used by the embedding application will lead to the Scripting user automatically logging in using the same cookie that the embedding application used.
If receiving an error message when attempting login of
"No active SSO provider was available to validate the login. Matching Entity ID not found", then you can check for the value provided as part of the SAML response from the provider.
Enable Debug-level logging for the CallScripter.Security.SSO.SsoManager logger name, and then check the
web.log file after attempting an SSO login; the entire SAML response will be logged, and the value of the
<saml2:Audience> node should match the value of the Identifier (Entity ID) for the selected SSO provider.
