This article describes Single Sign-On and how it is used in Nexus Hybrid Access Gateway.
Single Sign-On (SSO) permits users to enter their credentials once, which then gives them access to several resources without the need to re-authenticate later on. Policy expressions help and assist the user with internal credentials. When using the system for the first time, users might be prompted for internal credentials as additional user ID and password. But the system administrators have the possibility to pre-populate this and even make a dynamic lookup to get the values. If the user has been prompted to add individual SSO credentials, they are then stored per user account and retrieved whenever the user accesses resources registered in an SSO domain. If credentials are invalid or changed, the user will be prompted to enter them again.
The system administrators can enabled SSO for web based access including HTML5 clients and some TCP protocols using the Access Client. Almost any web resource requiring additional user information can benefit and use SSO. SSO can also be used for well defined protocols as Microsoft Terminal server (RDP), Secure Shell (SSH) and Telnet.
When SSO is enabled and used, it performs a POST or a GET request to a URL:
The form data usually contains a user name and a password together with some static fields. The variables [$username], [$password], and [$domain] are replaced by the stored user name, password and NTLM domain from the SSO database. If the back-end server requires the logon request to contain specific headers, these can be supplied as additional headers.
There are two methods of using SSO:
In Hybrid Access Gateway, SSO domains are configured to enable Single sign-on for resources using the same user credentials. The SSO domain specifies how SSO will be used for the resources included in the domain. When user credentials are modified, the changes apply to all resources in the SSO domain.
SSO domains are available in two domain types (authentication):
Depending on which domain type you choose, different domain attributes can be associated with the SSO domain. Both domain types can be protected by access rules.
Text-based authentication is used to send authentication information as text, with different attributes defining the information needed.
For the domain type text, the available domain attributes are:
Which domain attributes you add to the domain type Text depends on the authentication method used. The domain attributes normally used for the different authentication methods are described below.
Internal authentication protocols supported:
The logon form is added to the resource host to enable form-based SSO. Configuration of the logon form includes whether SSO should perform POST or GET when triggered, the URL to GET or POST data to, as well as form data sent to the server. A form response message can be used to determine whether a logon was successful or not. Configuration of the form response message, that will appear when the user has logged on or failed to log on, includes a URL to which the response from the form should be sent, and a text string form response used to decide if the authentication is successful or unsuccessful.
SSO to cloud applications
Cookie-based authentication is used to send authentication information in HTTP headers. A common use of cookie SSO is when back-end applications only want to read the authentication information at the very first request.
For the domain type cookie, the available domain attributes are:
See Add Single Sign-On domain for more information.