For self-managed customers only, LILT supports Single Sign-On (SSO), allowing users to sign in to LILT using an identity provider other than LILT. Organizations can utilize SSO to simplify account management and reduce password fatigue. Currently, a user account must pre-exist in the LILT system before SSO can be used to authenticate the user.

​
Google SSO

LILT customers can sign in via their Google account. After being invited to join LILT by someone in your organization, you can create an account using Google Sign-On. Users with existing LILT accounts that use traditional username/password sign in can access their accounts and all their data using Google Sign-On with an email address that matches their existing account. Users may use both sign-in methods interchangeably.

​
OpenID Connect

LILT Platform users can sign in through their organization’s SSO once configured via OpenID Connect (OIDC). OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750). It simplifies the way to verify the identity of users based on the authentication performed by an Authorization Server and to obtain user profile information in an interoperable and REST-like manner. OIDC can be leveraged through many identity providers such as Amazon, Microsoft, Okta, etc.

​
Configuration

  • LILT must be registered as a client with your OpenID Connect (OIDC) provider before installation. Client key, secret, and configuration parameters need to be configured during installation. Those parameters will be set by your systems administrator under the front:config:SSO property in the helm values file.
  • A LILT installation can support only one OIDC configuration at a time.
  • OpenID support has currently been tested with the following two signing algorithms: SHA256 and HS256.
  • The integration supports encryption with the OpenID provider via HTTPS but does not additionally encrypt the OpenID payload.

​
Usage

  • After configuration, OIDC authentication can be used to authenticate existing LILT accounts and their data.
  • To create new user accounts, users must first be invited by email using the “New member” screen in the LILT Organizations tab. After being invited, new users can sign in using the SSO button on the sign-in page.
  • NOTE: Automated user provisioning and de-provisioning is not supported in LILT.

​
WSO2

In order to install WSO2, a system administrator will need to follow the directions below:
  1. TODO: What values need edited at <install dir>/wso2/on-prem-values.yaml
  2. Run the following script to install WSO2: <install dir>/install_scripts/install-wso2.sh

​
Direct Integration

The version 1.20.0 (September 2023) release of LILT Enterprise supports two new kinds of customization of the Single Sign On feature: “custom certs” and “non-standard overrides”. The intent is to expand the environments where SSO can be used. These customizations are discussed in more detail in the following section, where we will reference the configuration shown immediately below. This particular configuration illustrates using custom certificate info, as well as overrides to standard OIDC behaviour, so that login using Active Directory Federation Services (ADFS) on Windows 2016 can be achieved. front: onpremValues: env: # SSO configurations # # OIDC SINGLE_OIDC_PROVIDER_ENABLED: true SINGLE_OIDC_PROVIDER_CLIENT_ID: "lilt" SINGLE_OIDC_PROVIDER_CLIENT_SECRET: "SAMPLE" SINGLE_OIDC_PROVIDER_ID_TOKEN_SIGNED_RESPONSE_ALG: "RS256" SINGLE_OIDC_PROVIDER_ISSUER_NAME: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs" SINGLE_OIDC_PROVIDER_ISSUER_AUTH_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/authorize/" SINGLE_OIDC_PROVIDER_ISSUER_TOKEN_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/token/" SINGLE_OIDC_PROVIDER_ISSUER_USERINFO_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/userinfo" SINGLE_OIDC_PROVIDER_ISSUER_JWKS_URI: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/discovery/keys" # # OIDC - overrides for working with ADFS SINGLE_OIDC_PROVIDER_OVERRIDES_RESOURCE_QUERY_PARAM: "urn:microsoft:userinfo" SINGLE_OIDC_PROVIDER_OVERRIDES_IDTOKEN_CLAIM_NAME_FOR_LILT_EMAIL_ADDRESS: "upn" config: # singleOidcProviderTlsOptions provides a means to customize HTTP requests made from the front container # to the OIDC Provider, when using the SingleOidcProvider SSO feature. Using these options means you # should NOT use any other OIDC-based login strategy besides that of the SingleOidcProvider SSO feature, or at # least be aware other strategies implemented via the openid-client library will also be affected by these options. singleOidcProviderTlsOptions: # existingSecret should be set to true if you are going to manage the secret yourself; otherwise set existingSecret # to false and the template will manage the secret. If managing the secret yourself, you can provide key-value pairs # in the secret for any of the following keys: # ca, cert, key, passphrase, crl, pfx # However, you MUST also provide a non-empty string value in the map below for the keys that you want to be used. # It does not matter what non-empty string you provide below in that case -- e.g., # ca: "use-the-existing-secret-value" # added below would cause your existing secret's ca value to be used. existingSecret: false secretName: "single-oidc-provider-tls-options" # ca, cert, key, passphrase, crl, and pfx are used to customize HTTP calls from the oidc-client library to the OIDC Provider # Only those with non-empty values will be used; all others will be ignored. # If existingSecret is false, the the values you specify below should be base64 encoded. # Their meaning can be found at: https://nodejs.org/api/tls.html#tlscreatesecurecontextoptions ca: |- SAMPLE cert: |- SAMPLE key: "" passphrase: "" crl: "" pfx: ""

​
SSO configuration format changes, starting at version 1.19.0

Changes were made to how the SSO configuration values are specified, starting with version 1.19.0. Note that the “regular” SSO-related configuration values are now specified as environment variables, nested under front.onpremValues.env has shown in this excerpt: front: onpremValues: env: # SSO configurations # # OIDC SINGLE_OIDC_PROVIDER_ENABLED: true SINGLE_OIDC_PROVIDER_CLIENT_ID: "lilt" SINGLE_OIDC_PROVIDER_CLIENT_SECRET: "SAMPLE" SINGLE_OIDC_PROVIDER_ID_TOKEN_SIGNED_RESPONSE_ALG: "RS256" SINGLE_OIDC_PROVIDER_ISSUER_NAME: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs" SINGLE_OIDC_PROVIDER_ISSUER_AUTH_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/authorize/" SINGLE_OIDC_PROVIDER_ISSUER_TOKEN_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/token/" SINGLE_OIDC_PROVIDER_ISSUER_USERINFO_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/userinfo" SINGLE_OIDC_PROVIDER_ISSUER_JWKS_URI: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/discovery/keys"

​
SSO TLS customization

Communication from the LILT app to your OIDC IdentityProvider occurs over a connection secured by TLS. For this communication to be successful, certificate information is exchanged and verified. In many environments, this verification can succeed using well-known CertificateAuthority information that is part of the default network stack in nodejs (the platform used to implement the SSO feature). In some environments, it will be necessary to provide additional TLS-related configuration. Support for doing so was added to LILT Enterprise starting at version 1.20.0.

​
singleOidcProviderTlsOptions

Specifically, it is now possible, via the front.onpremValues.config.singleOidcProviderTlsOptions object, to provide the following configuration values affecting the TLS communication for calls made from the LILT appserver to your OIDC IdentityProvider:
  • ca
  • cert
  • key
  • passphrase
  • crl
  • pfx
The meaning of the above six parameters can be found in the nodejs documentation at: TLS (SSL) | Node.js v24.6.0 Documentation In testing where Active Directory Federation Services (ADFS), running on Windows Server, was used as the IdentityProvider, it was necessary to specify ca and cert values, but not the others. Further instructions for using these configuration values can be found in the comments in the YAML shown at the start of this SSO section.

​
Using ADFS 2016 in lieu of standard OIDC Identity Provider

Microsoft’s ADFS 2016 does not conform to the OIDC standard when acting as an identity provider. Starting with version 1.20.0, the LILT application can work around this non-conformance, if you leverage two new environment variables, as discussed below.

​
SINGLE_OIDC_PROVIDER_OVERRIDES_RESOURCE_QUERY_PARAM

ADFS 2016 needs an additional “resource” query parameter to be used when calling the OIDC authenticaiton endpoint. Set the SINGLE_OIDC_PROVIDER_OVERRIDES_RESOURCE_QUERY_PARAM as shown in the YAML at the start of this SSO documentation (above).

​
SINGLE_OIDC_PROVIDER_OVERRIDES_IDTOKEN_CLAIM_NAME_FOR_LILT_EMAIL_ADDRESS

ADFS 2016 does not include the expected email property in the response from the Userinfo OIDC endpoint. As a workaround, you can adjust the settings in ADFS 2016 to provide the user’s email address as the value of a claim in the ID_TOKEN. Use the SINGLE_OIDC_PROVIDER_OVERRIDES_IDTOKEN_CLAIM_NAME_FOR_LILT_EMAIL_ADDRESS setting as shown in the YAML at the start of this SSO documentation (above) to tell your LILT installation which claim in the ID_TOKEN will contain the email address. The following articles might be helpful when attempting to configure ADFS to provide an email address via an ID_TOKEN claim: Note that in the example shown above (and excerpted again below), the “upn” property in the IdToken is being leveraged, but it may or may not correspond to an email address used by your users. It likely is in the same format as an email address, and uniquely identifies a user in your IdentityProvider, and so may be suitable for using in this way if it is not possible to provide an email address via a property in the IdToken. front: onpremValues env: SINGLE_OIDC_PROVIDER_OVERRIDES_RESOURCE_QUERY_PARAM: "urn:microsoft:userinfo" SINGLE_OIDC_PROVIDER_OVERRIDES_IDTOKEN_CLAIM_NAME_FOR_LILT_EMAIL_ADDRESS: "upn"

​
SSO Troubleshooting

​
Communication paths

The OpenIDConnect (OIDC) standard used in the implementation of SSO in LILT Enterprise depends on two communication paths being open and configured properly:
  • the path from user’s browser to the OIDC IdentityProvider
  • the path from the LILT app-server (front pod in the Kubernetes cluster) to the OIDC IdentityProvider
Testing communication path from user’s browser to the OIDC IdentityProvider:
  • It will be apparent whether that first path is open and functioning when the user is redirected to the sign-in page hosted by your OIDC IdentityProvider. If that sign-in page loads, then that path is functioning. (To be clear, this is not the initial “Sign in to LILT” page hosted by the LILT app; rather, it is the page that loads after clicking the “Sign in with SSO” button on the “Sign in to LILT” page.)
  • It is also informative to load in your browser the “…well-known…” configuration page served up by your OIDC IdentityProvider. The URL will depend on how you have configured your IdentityProvider, but will be something like “https://YOUR_IDP_DOMAIN_NAME/adfs/.well-known/openid-configuration.
Testing communication path from the LILT app-server to the OIDC IdentityProvider: Determining whether that second path is open and configured appropriately is more challenging. The following steps can be used to help diagnose when there is a problem. # ssh into the master vm for the Kubernetes cluster # (exactly how to do that is site specific) # store the front pod name in a variable, for ease of use fpod=$(kubectl get pods | grep front | awk '{print $1}') # "kubectl exec" into the "front" container of the "front" pod kubectl exec --stdin --tty $fpod -- /bin/sh # # At this point, you should have a shell prompt in that front container # # Use curl to verify domain name of your IdentityProvider can be resolved curl YOUR_IDP_DOMAIN_NAME ## Failure to resolve will look something like this: ## ## curl: (6) Could not resolve host: YOUR_IDP_DOMAIN_NAME; Unknown error ## # Use curl --insecure to verify the ".well-known" configuration page served by # your IdentityProvider can loaded, ignoring certificate issues. # (Note that the "adfs" in the URL below may not match what your IdentityProvider # uses. But there should be a URL with ".well-known" that is valid. curl --insecure https://YOUR_IDP_DOMAIN_NAME/adfs/.well-known/openid-configuration # If successful, the curl command above should return a result something # similar to: ## {"issuer":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs","authorization_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/authorize\\/","token_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/token\\/","jwks_uri":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/discovery\\/keys","token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic","private_key_jwt","windows_client_authentication"],"response_types_supported":["code","id_token","code id_token","id_token token","code token","code id_token token"],"response_modes_supported":["query","fragment","form_post"],"grant_types_supported":["authorization_code","refresh_token","client_credentials","urn:ietf:params:oauth:grant-type:jwt-bearer","implicit","password","srv_challenge","urn:ietf:params:oauth:grant-type:device_code","device_code"],"subject_types_supported":["pairwise"],"scopes_supported":["winhello_cert","user_impersonation","vpn_cert","logon_cert","profile","openid","allatclaims","email","aza"],"id_token_signing_alg_values_supported":["RS256"],"token_endpoint_auth_signing_alg_values_supported":["RS256"],"access_token_issuer":"http:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/services\\/trust","claims_supported":["aud","iss","iat","exp","auth_time","nonce","at_hash","c_hash","sub","upn","unique_name","pwd_url","pwd_exp","mfa_auth_time","sid"],"microsoft_multi_refresh_token":true,"userinfo_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/userinfo","capabilities":["kdf_ver2"],"end_session_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/logout","as_access_token_token_binding_supported":true,"as_refresh_token_token_binding_supported":true,"resource_access_token_token_binding_supported":true,"op_id_token_token_binding_supported":true,"rp_id_token_token_binding_supported":true,"frontchannel_logout_supported":true,"frontchannel_logout_session_supported":true,"device_authorization_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/devicecode"} # Use curl to verify certificates used by the TLS setup are ok curl https://YOUR_IDP_DOMAIN_NAME/adfs/.well-known/openid-configuration # If successful, you should see the same result as the curl --insecure command. # If instead you see something like the output below, you may need to configure # one or more of the parameters of # # front.onpremValues.config.singleOidcProviderTlsOptions # # as described in sections above. # ## curl: (60) SSL certificate problem: unable to get local issuer certificate ## More details here: <https://curl.se/docs/sslcerts.html> ## ## curl failed to verify the legitimacy of the server and therefore could not ## establish a secure connection to it. To learn more about this situation and ## how to fix it, please visit the web page mentioned above. ## command terminated with exit code 60

​
Deleting session information

When troubleshooting the SSO configuration, it may be helpful to delete session information stored in the browser for both the LILT app and your OIDC IdentityProvider. To delete session information for the LILT app, load the /signin page of the LILT app, and use your browser’s tools to delete the cookies and storage associated with the LILT app domain name. To delete session information associated with your OIDC IdentityProvider, load the “…well-known…” configuration page (e.g., “https://YOUR_IDP_DOMAIN_NAME/adfs/.well-known/openid-configuration) in the browser, and use your browser’s tools to delete the cookies and storage associated with your IdentityProvider. Note that if you do not delete the session info associated with your OIDC IdentityProvider, when you click on “Sign in with SSO” it may skip taking you to the IdentityProvider’s login screen to type in password information; instead, it will re-use the previous successful login session, if any.

​
Configuration to TEMPORARILY enable debug logging for SSO

The following configuration will cause details about the HTTP/TLS communication with the OIDC identity provider to be included in the front pod logs. PLEASE BE CAREFUL USING THESE OPTIONS. This extra logging should not be enabled for production use. front: onpremvalues: env: DEBUG: "openid-client,lilt:singleOidcProvider" NODE_DEBUG: "http,tls" The options can be adjusted to include only a subset of the debug logging available. For instance, you can just specify the DEBUG setting shown, but leave out the one for NODE_DEBUG.