Zendesk Support supports Secure Assertion Markup Language (SAML), which lets you provide single sign-on (SSO) access to Support. With SSO, users can sign in once using their company sign-in form to gain access to multiple systems and service providers, including Support.
You can enable SAML single sign-on only for Support agents and admins, only for end users, or for both groups.
As a Zendesk admin, your role consists of enabling the SAML SSO option in Support. See the following topics:
- How SAML SSO for Support works
- Requirements for enabling SAML SSO
- Enabling SAML SSO
- Managing users in Support after enabling SAML SSO
The IT team in a company is usually responsible for setting up and managing the company's SAML authentication system. Their role is to implement SSO for Zendesk on the system. Refer the team to the following topic in this article:
SAML single sign-on is available on the Professional and Enterprise plans. If you're on Team or above, you can also set up single sign-on using JWT remote authentication. See Setting up single sign-on with JWT.
How SAML SSO for Support works
SAML for Support works the way SAML does with all other service providers. A common use case is a company where all user authentication is managed by a corporate authentication system such as Active Directory or LDAP (generically referred to as an identity provider, or IdP). Zendesk establishes a trust relationship with the IdP and allows it to authenticate and sign in users to Support.
A common user case is a user who signs in to their corporate system at the beginning of the work day. Once signed in, they have access to other corporate applications and services (such as email or Zendesk Support) without having to sign in separately to those services.
If a user attempts to sign in directly to Zendesk Support, they are redirected to your SAML server or service for authentication. Once authenticated, the user is redirected back to your Support account and automatically signed in.
Another supported workflow is giving users access to Zendesk Support after they sign in to your company's website. When a user signs in to the website using their website credentials, the website sends a request to the identity provider to validate the user. The website then sends the provider's response to the SAML server, which forwards it to your Zendesk Support account, which grants a session to the user.
Requirements for enabling SAML SSO
Meet with the team in your company responsible for the SAML authentication system (usually the IT team) to make sure your company meets the following requirements:
The company has a SAML server with provisioned users or connected to an identity repository such as Microsoft Active Directory or LDAP. Options include using an in-house SAML server such as OpenAM, or a SAML service such as Okta, OneLogin, or PingIdentity.
If using an Active Directory Federation Services (ADFS) server, forms-based authentication must be enabled. Zendesk does not support Windows Integrated Authentication (WIA). For more information, see Setting up single sign-on using Active Directory with ADFS and SAML.
- Zendesk-bound traffic is over HTTPS, not HTTP
- The remote login URL for your SAML server (sometimes called SAML Single Sign-on URL)
- (Optional) The remote logout URL where Zendesk can redirect users after they sign out of Zendesk
- (Optional) A list of IP ranges to redirect users to the appropriate sign-in option. Users making requests from the specified IP ranges are routed to the remote SAML authentication sign-in form. Users making requests from IP addresses outside the ranges are routed to the normal Zendesk sign-in form. If you don't specify a range, all users are redirected to the remote authentication sign-in form.
- The SHA2 fingerprint of the SAML certificate from your SAML server. X.509 certificates are supported and should be in PEM or DER format. There is no upper limit on the size of the SHA fingerprint.
The next step is to enter the information in Support to enable SSO. See Enabling SAML SSO.
The IT team may require additional information from Zendesk to configure the SAML implementation. Refer them to the Technical implementation worksheet in this article.
Enabling SAML SSO
You can enable SAML single sign-on only for end users, only for agents, or for both groups. If you're using both JWT and SAML, you need to select one as the primary authentication method. When signing into Zendesk, users will redirected to your primary sign-in page. Users can sign in with the secondary method by going to the secondary sign-in page. For details, see Using different SAML and JWT SSO (single sign-on) for agents and end users.
Before you start, obtain the required information from your company's IT team. See Requirements for enabling SAML SSO.
You must sign in to Zendesk Support as an administrator to enable SAML single sign-on.
To enable SAML single sign-on in Zendesk Support
- Click the Admin icon () in the sidebar, then select Security from the Settings category.
- Select the Admins & Agents or End-users tab.
You can enable SAML single sign-on only for end users, only for agents, or for both groups.
You can't enable SAML for one group if the JWT SSO option is enabled for the other group. See Setting up single sign-on with JWT. If you want to use single sign-on for both groups, both must be SAML or both must be JWT.
The End-users tab is not available until you activate Help Center. See Getting started with the Help Center.
- Select the Single sign-on (SSO) option, then click the SAML checkbox.
- For SAML SSO URL, enter the remote login URL of your SAML server.
- Enter the Certificate fingerprint. This is required for us to communicate with your SAML server.
- (Optional) For Remote logout URL, enter a logout URL where Zendesk can redirect users after they sign out of Zendesk.
- (Optional) For IP ranges, enter a list of IP ranges if you want to redirect users to the appropriate sign-in option. Users making requests from the specified IP ranges are routed to the remote SAML authentication sign-in form. Users making requests from IP addresses outside the ranges are routed to the normal Zendesk sign-in form. Don't specify a range if you want all users to be redirected to the remote authentication sign-in form.
- Enable or disable Passwords depending on your needs.
Single sign-on might not cover all use cases. For example, a Zendesk password is required to access your Support account from many Zendesk integrations, or to use the Zendesk API or Apps framework.
If passwords are enabled and you subsequently disable them, all passwords will be permanently deleted within 24 hours.
If passwords are enabled and agents manually add a Zendesk password to their account, the passwords don't expire.
- If you disabled Zendesk passwords, select the menu option that specifies whether only the account owner or admins (which includes the account owner) can be granted access to the account in case the sign-in provider does down.
To gain access, the account owner or an admin requests to receive an email containing an one-time access link. Clicking the link grants the person access to the account. No password is required. See Accessing the account if passwords are disabled.
- Click Save.
Managing users in Support after enabling SAML SSO
After enabling SAML single sign-on in Support, changes made to users outside Support sync to your Support account. For example, if a user is added to your internal Active Directory or LDAP system, the user is automatically added to your Support account. If a user is deleted in your internal system, the user will no longer be able to sign in to Support. However, their account will still exist in Support.
By default, the only user data stored in Support when single-sign on is enabled is the user's name and email address. Zendesk does not store passwords. As a result, you should disable any automated email notifications from Support about passwords. See Disabling password notification emails from Support.
To provide a better customer experience, you might want to store more than just the user's name and email address in Support. See Obtaining additional user data for Support.
Disabling password notification emails from Support
When a user is added to a Support account, an automatic email notification may be sent to the user asking them to verify their email address and to create a username and password.
A Zendesk user profile is created for any new user who accesses your Support account through SAML. Because they're authenticated with a non-Zendesk password, the profile is created without a password because they don't need to sign in to Support. However, by default every new user gets an email notifying them to verify their email address and create a username and password.
- In the Account emails section, "Also send a welcome e-mail when a new user is created by an agent or admin"
- "Allow users to change their passwords"
Obtaining additional user data for Support
The only user data required by Support from your authentication system is the user's name and email address. However, you can get more data by asking your IT team to add user attributes to the SAML assertions the identity provider sends to Zendesk when users sign in.
A SAML assertion contains one or more statements about the user. One statement is the authorization decision itself – whether or not the user was granted access. Another statement can consist of attributes describing the signed-in user.
Zendesk supports the following additional user attributes for signed-in users. Define your data requirements in Support, then meet with your IT team to discuss adding user attributes to the SAML assertions.
|organization||Name or id of an organization to add the user to. The external_id attribute of an organization is not supported. If the organization doesn't exist in Zendesk, it won't be created. The user will still be created, but they won't be added to any organization.|
|organizations||Comma separated values such as
|organization_ids||Comma separated values such as
|ou||Name of an organization unit. Specify it as an
|phone||A phone number, specified as a string.|
|tags||Tags to set on the user. The tags will replace any other tags that may exist in the user's profile.|
|remote_photo_url||URL for a photo to set on the user profile.|
|locale (for end-users)
locale_id (for agents)
|The locale in Zendesk, specified as a number. To get a list of valid numbers, see Locales in the API docs.|
|role||The user's role. Can be set to "user", "agent", or "admin". Default is "end-user".|
|custom_role_id||Applicable only if the value of the role attribute above is "agent". You can get the ids of your custom roles with the Custom Roles API.|
|external_id||A user id from your system if your users are identified by something other than an email address, and if their email addresses are subject to change. Specified as a string.|
|user_field_<key>||A value for a custom user field in Zendesk Support. See Adding custom fields to users. The <key> is the field key asssigned to the custom user field in Zendesk Support. Example:
Zendesk also supports a series of InCommon Federation Attributes to set user attributes as part of the sign in. Examples:
|Friendly name||SAML2 formal name|
|ou (organization unit)||urn:oid:22.214.171.124|
Technical implementation worksheet
This section is for the team in the company responsible for the company's SAML authentication system. It provides details about the Zendesk SAML SSO implementation.
Required user attributes
Zendesk requires the following two user attributes in the SAML assertion:
|Email of the user signing in. Uniquely identifies the user in Zendesk Support.|
|name||The name of this user. A user in Zendesk is created or updated in accordance with this.|
Zendesk supports addtional user attributes. See Obtaining additional user data for Support for a list of supported attributes. Talk to your Zendesk Support admin about their data requirements in Support.
Configuring the identity provider for Zendesk
where your_subdomain is the Zendesk Support subdomain. If unsure of the subdomain, ask your Zendesk admin.
Zendesk enforces the
Configuring the SAML server for Zendesk
Some SAML servers may require the following information when configuring an integration with Zendesk:
Access Consumer Service (ACS) URL: Specify https://accountname.zendesk.com/access/saml (case sensitive), where 'accountname' with your Support subdomain
Redirects to SAML Single Sign-on URL: Use HTTP POST
Hashing algorithm (ADFS): Zendesk supports the SHA-2 algorithm when using Active Directory Federation Services (ADFS)
Parameters returned to your remote sign-in and sign-out URLs
When redirecting users to your authentication system, Zendesk appends the following parameters to the remote sign-in and remote sign-out URLs.
|brand_id||The brand of the Help Center the user was on when they attempted to sign in. For more information, see Creating a Help Center for one of your brands.|
|Email of the user signing out.|
|external_id||A unique identifier from your system stored in the Zendesk user profile.|
|brand_id||The brand of the Help Center the user was on when they signed out. For more information, see Creating a Help Center for one of your brands.|
If you prefer not to receive email and external id information in the sign-out URL, ask your Zendesk admin to specify blank parameters in the Remote logout URL field in the admin interface. See Enabling SAML SSO. Example:
Troubleshooting the SAML configuration for Zendesk
Zendesk expects the following SAML 2.0 metadata:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <EntityDescriptor entityID="your_subdomain.zendesk.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"> <SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat> <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://accountname.zendesk.com/access/saml"/> <!-- Note: replace 'accountname' with your Zendesk subdomain --> </SPSSODescriptor> </EntityDescriptor>
Zendesk expects a SAML assertion that looks as follows:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s2202bbbb afa9d270d1c15990b738f4ab36139d463" InResponseTo="_e4a78780-35da-012e-8ea7-005056 9200d8" Version="2.0" IssueInstant="2011-03-21T11:22:02Z" Destination="https://accountname.zendesk.com/access/saml"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">myidp.entity.id </saml:Issuer> <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Value="urn:oasis:names:tc:SAML:2.0:status:Success">
Note: Replace 'accountname' in the
Destination attribute with your Zendesk subdomain.
Zendesk expects user attributes to be specified in an assertion's attribute statement (
<saml:AttributeStatement>) as in the following example:
<saml:Attribute Name="organization"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Acme Rockets</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="tags"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">tag1 tag2</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="phone"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">555-555-1234</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="role"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">agent</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="custom_role_id"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">12345</saml:AttributeValue> </saml:Attribute>
For the names and descriptions of the user attributes supported by Zendesk, see the table in Obtaining additional user data for Support above.