Si prega di notare che questo tutorial è disponibile solo in inglese, poiché è principalmente rivolto a utenti con un background più tecnico, per i quali l'inglese è lo standard de facto.
Enable your single sign-on system (Identity Provider / IdP) to connect to your Userlike account or one of your Userlike organizations using OpenID IdP via OpenID Connect.
Operators and permissions can be managed centrally to meet your security and compliance requirements.
Another advantage is that no separate login credentials are required for Userlike.
Set up an identity provider to connect with Userlike
Please contact us if you are interested in this feature.
We will then check the implementation together with you.
The following things need to be configured:
- A set of OpenID Connect client credentials (client ID and secret; these will be used by Userlike to validate the identity and fetch additional user data). For this usually a “client” or “application” needs to be created.
- Custom metadata in the identity provider to describe the user’s name, email and role and possibly some other properties in the corresponding Userlike operator account
- Configure the client/application so that responses will include this custom metadata or define a custom OpenID Connect scope that contains these attributes, and give the client/application access to it
- Configure the following allowed redirect/callback URLs for the client/application:
- https://app.userlike.com/sso/callback/oidc/
Here’s a list of custom metadata used by Userlike (the OpenID Connect standard calls these fields “claims” when including them in user data):
- The ID of the organization the operator should belong to
- required if the SSO setup is for the whole customer account (spanning across multiple organizations), to know where the operator account should be added. Not used if the SSO setup is for a single organization
- The operator role (one of the following: “owner”, “manager”, “admin”, “agent”, “staff”, “analyst”)
- required
- The operator’s email
- required (this is usually a standard claim in OpenID IdPs, called “email”)
- The operator’s first name
- required (this is often a standard claim in OpenID IdPs, called “given_name”)
- The operator’s last name
- required (this is often a standard claim in OpenID IdPs, called “family_name”)
- The ID of the operator group the operator belongs to
- optional (the default operator group will be used if this is not defined)
- A list of the operator’s skill IDs
- optional (no skills will be assigned if this is not set)
- The operator’s ID (once known; this can be set prior to changing the user’s email in the IdP so that the change can be reflected in Userlike; otherwise, the user’s next login will create a new operator)
The names of these claims can be chosen freely by the IdP administrator; the Userlike SSO setup can use any name for each attribute.
To allow setup on the Userlike side, the following information needs to be provided:
- The client/application credentials created earlier, consisting of a client ID and a client secret
- The IdP’s OpenID Connect autodiscovery URL (provider-specific)
- The names of the attributes set up earlier
- The desired SSO domain
- This will be entered by users when starting an SSO login, or it can be used as part of a bookmarkable SSO entry point. It should consist of only lowercase letters and digit as well as dots (.), hyphens (-) and underscores (_). The first character must be a letter or digit. Example domains for a company called “Global Apple Juice Inc.”: “globalapplejuice”, “global-apple-juice", “globalapplejuice.com”, “gaj_inc”. Since each domain can exist only once in Userlike, it should not be too generic. If in doubt, use your website’s domain (though of course domains with extended international character sets don’t work with our naming restrictions).