On default, SSO will not be performed when multiple Identity Sources are visible to the user even when explicitly activating SSO. Either hide all other Identity Sources that are not used for SSO or specify which Identity Source needs to be used for SSO.
SSO will automatically be performed on OAuth 2.0 configurations with a single visible Identity Source, all other SSO protocols require to explicitly activate SSO. There are several ways to activate SSO, these are described below:
The liquit agent has several configuration options available within the supplied Agent.xml, which can be modified on the Liquit servers.
Liquit agent supports SSO by enabling the “Login\SSO” option.
When multiple Identity Sources are visible, you can specify the deafult Identity Source by providing the name in the "Login\IdentitySource" option.
For more information about available URL parameters, see the corresponding page.
SSO can be activated by adding the ?sso=1 option to the URL.
When multiple Identity Sources are visible, you can specify the “identitySource” option to the URL.
workspace.liquit.com should be replaced by your Liquit FQDN.
- HTTP Headers
SSO can be activated by adding the following HTTP headers (to the request to: /api/identity/domains):
|X-Liquit-SSO||Value needs to be set to 1 to activate SSO|
|X-Liquit-IdentitySource||Value needs to be the name of the Identity Source to use for SSO.|
SSO with AD FS
Liquit supports OAuth2 based authentication in combination with an Active Directory Identity Source to achieve SSO with other applications. When activated, Liquit will no longer handle authentication using its login screen, but will delegate authentication to the OAuth2 token service.
When multiple Identity Sources are visible to the user for logon, Liquit will switch to the OAuth2 service after entering the username in the logon screen.
This document describes how to configure AD FS as authentication source for an Active Directory. By delegating the authentication responsibility from the Liquit server to the AD FS server.
For this example we will use the following URLs: workspace.liquit.com, this URL should be replaced by your Liquit FQDN.
On one of the AD FS server, open PowerShell with the AD FS module.
Execute the following command to define the Liquit endpoint:
Add-ADFSClient -Name "Liquit" -ClientId "liquit" -RedirectUri "https://workspace.liquit.com/api/auth/token/end"
For AD FS version 4 and up an extra setting is required:
Grant-AdfsApplicationPermission -ClientRoleIdentifier "liquit" -ServerRoleIdentifier "liquit"
Now open the “AD FS Management” interface and go to “Trust Relationships > Relying Party Trusts”.
Start the Add Relying Party Trust wizard, entering the following data:
- At “Data Source” select “Enter data about the relying party manually”
- Enter a display name to identify the trust, for example “Liquit”.
- Enter a relying party trust identifier, for example “liquit”.
After adding the Relying Party Trust, you need to edit the claim rules.
This option is available in the Context Menu of the newly created trust.
Add a new “Issuance Transform Rule”, with the following configuration:
- Select “Send LDAP Attributes as Claims”
- Claim Rule name: UPN
- Attribute store: Active Directory
- Mapping of LDAP attributes:
- LDAP: “User-Principal-Name”
- Outgoing: “UPN”.
Go to the Identity Source that needs to utilize ADFS for authenticating within the management interface of Liquit.
- On the “SSO” tab of the Identity Source, select the “OAuth 2.0” protocol.
- Enter the following configuration data for each setting:
- Client ID: liquit
- Resource: liquit
- Redirect URI: https://workspace.liquit.com/api/auth/token/end
- Token URI: https://adfs.liquit.com/adfs/oauth2/token
- Authorization URI: https://adfs.liquit.com/adfs/oauth2/authorize
- Logout URI: https://adfs.liquit.com/adfs/ls/?wa=wsignout1.0&wreply=https%3A%2F%2Fworkspace.liquit.com%2F
SSO with NTLM
Liquit supports NTLM based authentication in combination with an Active Directory Identity Source to achieve SSO.
A number of requirements are in place to use NTLM authentication.
- Only supported with an Active Directory based Identity Source.
- Identity Source name needs to match the Active Directory NetBIOS domain name, not the FQDN of the domain.
- NTLM protocol option needs to be selected on the Identity Source’s SSO tab.
- The Liquit server performing the NTLM authentication needs to be a member server in the Active Directory forest containing the domain.
When the clients machine will perform the NTLM authentication, a number of restrictions exist:
- Liquit’s FQDN needs to be added to the “Intranet Zone” within Internet Explorer to perform NTLM authentication for IE and the Liquit Launcher.
- Liquit's FQDN needs to be defined as a A-record within the DNS for both IE and the Liquit Launcher.
- Consult documentation for other supported browsers on how to activate NTLM authentication.
NTLM based authentication will only be triggered when SSO is explicitly activated for Liquit. Please see “Activating SSO” for available options.
SSO for Microsoft RDS
To facilitate SSO authentication for the newly created package we need to create a "Credential". To create a new credential go to (manage, credentials).
The initial pop-up asks you to select the type of credential.
With a template you specify a variable username and a variable password to authenticate. These credentials can be used, in this case to provide SSO for a user.
There are a number of options here:
|Name||The name of the credentials object.|
|Username||The account name used to connect to the network.|
|Verify Password||Choose whether you want to verify the provided password. This password will be asked the first time a user uses the package, after this point it will be stored for later use.|
After Creating the desired Credential Template can be assigned to the package imported from the RDS connector. Select the package and go to the Launch section of the actions.
Select your newly created credential template
SSO only works in Internet Explorer and on machines provided with an agent. The RDP file's provided by RDS need to be signed in order for SSO to work properly.