Using SAML for single sign-on (Professional and Enterprise) Follow

professional enterprise plans

Zendesk supports Secure Assertion Markup Language (SAML), which allows you to provide single sign-on (SSO) for your Zendesk using enterprise identity providers such as Active Directory and LDAP. Single sign-on using SAML is available on Professional and Enterprise.

Note: If you're on Team or above, you can set up enterprise single sign-on using JWT (JSON Web Token) remote authentication. See Setting up single sign-on with JWT (JSON Web Token).

Implementing single sign-on via SAML means that the sign in process and user authentication are handled entirely outside of your Zendesk. Your users will not directly visit your Zendesk Help Center to sign in. Instead users sign in to the corporate system (authenticated by Active Directory or LDAP for example) and click a link to access Zendesk and are automatically signed in. No need to enter separate sign-in credentials for Zendesk.

You can build a SAML server in-house (using OpenAM, for example) or choose a SAML service such as Okta, OneLogin, and PingIdentity. You'll need to set these up yourself outside of Zendesk. What you enable in Zendesk is the option to use SAML for single sign-on (see Enabling SAML single sign-on in your Zendesk below).

After you've enabled SAML (by building a SAML server yourself or by using one of the SAML services), all user management and authentication is handled outside of your Zendesk. However, changes made outside of your Zendesk are immediately synced back to your Zendesk. For example, if you add a user in your internal Active Directory or LDAP authentication system, the change is synced back through your SAML provider and the user is added to your Zendesk. If you delete a user in your system, the user will no longer be able to sign in to Zendesk (though their account will still exist in Zendesk).

The only user data that is stored in Zendesk is the user name and email address. However, you can also choose to sync the following user data: organization, phone, tags, given name, surname. You do this with by adding these attributes to your SAML assertion code. See User attributes that can be set in SAML. Zendesk does not store user passwords.

How SAML for Zendesk works

SAML for Zendesk works the way SAML does with all other service providers. The typical use case is that your users belong to a corporation and all user authentication is managed by your corporate authentication system (for example, Active Directory or LDAP), which is referred to generically as an identity provider (IdP). The service provider (SP), in this case of course Zendesk, establishes a trust relationship with IdP and allows that external IdP to authenticate users and then seamlessly sign them in to Zendesk. In other words, a user signs in at work and then has automatic access to the many other corporate applications such as email, your CRM, and so on without having to sign-in separately to those services. Aside from the convenience this provides to users, all user authentication is handled internally by a system that you have complete control over.

After you've enabled SAML as the type of single sign-on for your Zendesk, users who visit your Zendesk and attempt to sign in are redirected to your SAML server for authentication. Your users' identities can be stored either on the SAML server or can be validated by an identity directory such as Microsoft Active Directory or LDAP. Once authenticated, users are redirected back to your Zendesk and automatically signed in.

Another supported workflow is having the user sign in to your own website directly rather than to your Zendesk instance. 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, which grants a session to the user.

Returning visitors are automatically authenticated if their SAML assertions are cached. Assertions are packets of security information that are used to make access-control decisions.

Note: To access your Zendesk account from many of the Zendesk integrations, or to do any development work with the Zendesk API or App framework, you will need a Zendesk password. Single sign-on will not work in these cases.

Configuring your Zendesk for new users

A Zendesk user profile is created for any new user who accesses your Zendesk through SAML. Because they're authenticated with a non-Zendesk password, the profile is created without a password. It's not necessary to sign in to Zendesk. However, if you forget to make certain changes in Zendesk, every new user will get an email notifying them to verify their email address and create a username and password.

To prevent this from happening, make sure to uncheck the following options on the End-users (Customers) page of the Zendesk admin interface (Admin > Customers):
  • "Also send a welcome e-mail when a new user is created by an agent or admin"
  • "Allow users to change their passwords"

Configuring your SAML implementation

You have a number of options when considering a SAML service, including building a SAML server in-house (for example, OpenAM) or choosing a SAML service such as Okta, OneLogin, and PingIdentity.

To set up SAML in your Zendesk, you'll need the following:

  • A SAML server with provisioned users or connected to an identity repository such as Microsoft Active Directory or LDAP

  • The Remote Login URL for your SAML server (sometimes called SAML Single Sign-on URL)

  • The SHA1 or 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.

After you have your SAML server properly configured, you use the remote login URL and the SHA fingerprint to configure SAML within your Zendesk.

Other SAML servers may require additional information

Other SAML servers may ask for the following information when configuring an integration with Zendesk:

  • The Access Consumer Service (ACS) URL is (case sensitive)
    Note: In the URL above, replace 'accountname' with your Zendesk subdomain.
  • Redirects to SAML Single Sign-on URL are HTTP POST

  • Hashing algorithm (ADFS): Zendesk supports the SHA-1 and SHA-2 algorithm when using Active Directory Federation Services (ADFS)

Integration with Active Directory Federation Services (ADFS)

Currently, we only support Forms Based Authentication for ADFS. Integrated Windows Authentication is not supported.

User attributes that can be set in SAML

You can set the following user attributes for users signing in via SAML:

Table 1. Supported attributes
Attribute Description
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 org1, org2, org3
organization_id Example: 134211213
organization_ids Comma separated values such as 23423433, 234324324, 23432
ou Name of an organization unit. Specify it as an organization attribute.
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.

You set these attributes using an attribute statement in your SAML assertion. Example:

   <saml:Attribute Name="organization">
      <saml:AttributeValue xmlns:xs=""
      xsi:type="xs:string">Organization name</saml:AttributeValue>
   <saml:Attribute Name="tags">
      <saml:AttributeValue xmlns:xs=""
      xsi:type="xs:string">tag1 tag2</saml:AttributeValue>
   <saml:Attribute Name="phone">
      <saml:AttributeValue xmlns:xs=""
   <saml:Attribute Name="">
      <saml:AttributeValue xmlns:xs=""
   <saml:Attribute Name="">
        <saml:AttributeValue xmlns:xs=""
   <saml:Attribute Name="role">
      <saml:AttributeValue xmlns:xs=""
   <saml:Attribute Name="custom_role_id">
      <saml:AttributeValue xmlns:xs=""

Zendesk supports a series of InCommon Federation Attributes to set user attributes as part of the sign in. Examples:

Table 2. Attribute names
Friendly name SAML2 formal name
ou (organization unit) urn:oid:
displayName urn:oid:2.16.840.1.113730.3.1.241

Configuring the identity provider

Table 3. Identity provider attributes
Attribute Value

where your_subdomain is your Zendesk subdomain.

Zendesk enforces the AudienceRestriction attribute. See the code snippet at the end of this article.

Enabling SAML single sign-on in your Zendesk

With your SAML server configured and the information you need for setting up SAML in Zendesk at hand, sign in to your Zendesk as an administrator and follow this procedure.

To enable SAML in your Zendesk

  1. Click the Admin icon () in the sidebar, then select Security from the Settings category.
  2. 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. If you want to use single sign-on for both groups, both must be SAML or both must be JWT.

    If you started using Zendesk on or after August 21, 2013, the End-users tab is not available until you activate the Help Center. See Getting started with the Help Center.

  3. Select the SAML option.
  4. In the SAML SSO URL text box, enter the SAML login URL of your SAML server. Zendesk automatically adds a brand_id parameter to the URL. This is the Zendesk brand the user was on when they attempted to sign in.
  5. (Optional) Enter a logout URL where Zendesk can redirect users after they sign out of Zendesk.

    Zendesk automatically adds email, external_id, and brand_id parameters to the URL. If you prefer not having email and external id information in the URL, specify blank parameters in the logout URL. Example:

  6. You can optionally restrict access to users within a range of IP addresses.
  7. Enter the Certificate Fingerprint. This is required for us to communicate with your SAML server.

  8. Click Save.
Note: When you enable single sign-on via SAML (and JWT), be aware that passwords do not expire (even if your Zendesk password policy is set to High) because passwords are not stored in Zendesk. Additionally, if agents manually add a Zendesk password to their account, these passwords will not expire.

Troubleshooting your SAML configuration

If you have difficulty setting up SAML, you may find the following information helpful.

Here is the Zendesk SAML 2.0 metadata:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EntityDescriptor entityID="" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
    <SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=""/> <!-- Note: replace 'accountname' with your Zendesk subdomain -->

Zendesk expects a SAML assertion that looks like this:

<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=""> <!-- Note: replace 'accountname' with your Zendesk subdomain -->
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
        <samlp:StatusCode  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion
" ID="s2af6627280d72f061beb9f8b1635bd54cc2892317" IssueInstant="2011-03-21T11:22
:02Z" Version="2.0">
        <ds:Signature xmlns:ds="htt
                <ds:CanonicalizationMethod Algorithm=""/>
                <ds:SignatureMethod Algorithm=""/>
                <ds:Reference URI="#s2af6627280d72f061beb9f8b1635bd54cc2892317">

                        <ds:Transform Algorithm=""/>
                        <ds:Transform Algorithm=""/>
                    <ds:DigestMethod Algorithm=""/>
... my signature value ...
.... The rest of the signing cerrtificate ....
            <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier=""></saml:NameID> <!-- Note: replace 'accountname' with your Zendesk subdomain -->
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData InResponseTo="_e4a78780-35da-012e-8ea7-0050569200d8" NotOnOrAfter="2011-03-21T11:32:02Z" Recipient=""/></saml:SubjectConfirmation> <!-- Note: replace 'accountname' with your Zendesk subdomain -->
        <saml:Conditions NotBefore="2011-03-21T11:12:02Z" NotOnOrAfter="2011-03-21T11:32:02Z">
                <saml:Audience></saml:Audience>      <!-- Note: Replace 'subdomain' with your Zendesk subdomain -->
        <saml:AuthnStatement AuthnInstant="2011-03-21T11:22:02Z" SessionIndex="s25c49ea33a9598e2c930899f528b5f00fde2fe901">
Have more questions? Submit a request


  • 0

    Great info!

  • 0

    Will this allow us to use Google Apps as our Authentication provider?

  • 0

    @Nick: Ping Identity and others claim to let you use Google Apps as the IdP and integrate with SaaS apps over SAML, so I think this would work. If you're looking only for Google Apps authentication integration, I'd suggest maybe waiting a bit as this is in our product pipeline to be delivered soon.

  • 0

    Thanks very much Ben, I think I'll hold out for the Google Apps Authentication integration :)

  • 0

    \o/ I just signed on to with my Google Apps account, this is great, and I'll also sit in the boat until we can logon to our own domain using Google Apps. great work!

  • 0

    This service again fails to support remote, mobile, or branch office scenarios (with variable IP) for our use.

    It expects 100% of authentication (from customers and techs) from the remote don't plan on using this for just your internal staff if your IP changes.

    I have made suggestions to only have login requests from a special login URL (i.e. be sent for remote authentication, but it has made no progress in over a year in the Zendesk team priority list.

  • 0

    Did anyone get this to work in ADFS 2.0? I added the trust using the SAML 2.0 metadata successfully. However, I now need to create a custom claim so I don't get the issue below. Anyone get around this? If you can send the custom claim xml that would be greatly appreciated.


    The SAML authentication request had a NameID Policy that could not be satisfied.


    Name identifier format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress


    Exception details:

    MSIS1000: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SPNameQualifier: . Actual NameID properties: null.

    This request failed.

    User Action

    Use the AD FS 2.0 Management snap-in to configure the configuration that emits the required name identifier.

  • 0

    Huge thanks to Charles Stephen Thompson of SecondMarket for kindly sending us his write up on configuring ADFS 2.0. See attached PDF. 

  • 0

    It would be nice if Zendesk would support WIA in their SAML request for the 90% of your Enterprise customer's whom use Microsoft Active Directory.

    Also, your SAML SSO for only named IP's (and not a URL based) doesn't work for the 90% of your customer's that need to work outside their company firewall.

    Please fix!  Otherwise, heck of a support ticket system :)

  • 0

    Is it possible to update user metadata via the SAML token, as it is with the standard remote authentication?

  • 0

    Nope, uses the email (or UPN) only for SAML assertion token. If you gave it meta data in the claims provider, it would just ignore it.

    PS - You can use Microsoft Forefront Identity Manager with a custom sync source (Zendesk) using their API. Sync is separate then SAML authentication (Same for Office 365 and Google Apps).

    PSS - Zendesk pease fix WIA and support SAML outside of fixed IP addresses.

  • 0

    Wilson/John - you can set certain user attributes on the user during the SAML auth procedure:

    John, we'll have to get back to you on the WIA. Also, could you create a ticket on the IP/URL issue, I'm not sure I follow entirely.


  • 0

    Anyone having trouble with SAML logout with ADFS? We're using the following URL for logout:


    The logout appears to be successful, but an error is displayed in the browser and the following is returned in the Windows event logs:

    Encountered error during federation passive sign-out.

    Additional Data

    Exception details:

    Microsoft.IdentityServer.Web.RequestFailedException: MSIS7055: Not all SAML session participants logged out properly. It is recommended to close your browser.

    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSamlLogoutResponse(HttpSamlMessage samlMessage)

    at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SingleLogout(Uri returnUrl, Boolean wsFedInitiated)


    Microsoft's documentation offers little assistance with this. I do not have anything defined for the SAML logout end point on the relying trust. Is this my problem? Thanks.

  • 0

    Two questions:-

    1)What happens to the existing users in Zendesk?

    2)Will users be able to use their original Zendesk password as well as the one from AD?

  • 0

    I agree 100% with John G. Why don't you allow SAML auth to a specific URL? We have both our company and customers accessing Zendesk and need our clients to use the traditional form based authentication and all of our company to login via SSO. This is 2012 and tons of people work from their home offices that have dynamic IP's. This is critical and needs to be fixed. We can't use SAML for this one reason alone.

  • 0

    Am I correct in saying that the two URLs are and

  • 0

    I believe that the real requirement to run a mixed enterprise and customer helpdesk is to be able to choose the default authentication mechanism for the straight URL. Maybe this can already be done?

    Use Case 1: I would like the standard URL ( to provide u/p, google, twitter etc whilst agents/corporate users use a /access/saml login.

    Use Case 2: Other helpdesks that are enterprise focussed might want the straight URL to redirect to their saml provider (most often internal LAN), but have a mechanism "/access/normal" for corporate users at home.

    We might be able to get the Use Case 1 result by using the optional "IP ranges" filter above, set to something stupid like loopback, and direct the internal agents to use a SAML auth to a specific URL as requested above? The technical requirement is to send a 'relay state' to the SAML server to tie back to a zendesk session.

  • 0

    I've just thought of another limited solution until Zendesk recognise Use Case 1 as becoming more common.

    The hub and spoke model of Enterprise helpdesk solves use Case 1 with ticket sharing. Put customers on the spoke and SSO customers on another spoke. Messes up your branded knowledge base function

    Also - note - the help text on "IP Ranges" Requests from these IP ranges will always be routed via remote authentication. Requests from IP addresses outside these ranges will be routed to the normal login form." The /access/saml redirect fails unless you know the IP exit point on your network for all SSO users - not good for big organisations

    So I think the two new functions/fixes required (as reflected in most contributors comments) are:

    1. Default authentication method for straight URL - SSO yes/no

    2. - always redirects

  • 0

    I do want to echo the same from our side as well, we need to have SAML SSO for internal, and use for external customers, and using a IP range does not work, since we have agents work from home.


    So one more vote to get this "fixed" for the future.

  • 0


    We want to grow the tenancy in our customer by allowing agents to become established in the branded spoke (light or full). More revenue for zendesk, and lower support costs for us by using service advocates in the branded spoke.

    I really like the move to separate out the user and agent audience - looking forward to it reaching it's logical conclusion

    Modifying / Improving on my earlier posts above and unlikey to be trivial :)

    * I foresee two separate branded URLs for users and agents - allow a second CNAME and SSL

    * The authentication method choice should be tied to URLs to allow various access and business use case.


  • 0
  • 0

    Hi there,


    Am trying Zendesk since past couple of weeks. I need to know one thing. If

    I have enabled SSO login using SAML type, to what extent does zendesk

    stores the information about the user who logs in using SSO.

    Also what all information does Zendesk requires for authentication using


  • 0

    @Veeru, Zendesk stores the username once they've authenticated via SSO, but does not store any passwords since it only needs an assertion from the SAML service

    This article should define what information is required by Zendesk to setup SSO. If you need more information, please contact us at and we'll help you troubleshoot.

  • 0

    We have the Starter version of ZenDesk and I'm considering implementing OneLogin to provide SSO between our AD domain, Google Apps, and ZenDesk. According to your rep Avi W., only the more expensive ZenDesk plans support SAML but we could still use OneLogin for SSO. So there's a way to do SSO without SAML? How does that work? Apparently there's a lot I don't understand about SSO.

  • 0

    Hi Luke,

    It looks like your question was answered in a ticket. I'm putting some of the info here in case other users need it.

    While we do have SSO options for all plans (for example, Microsoft AD), SAML is limited to our Plus and Enterprise plans. You could take a look at our OneLogin integration as an alternative. If you have any other questions, let us know.

    Thanks for your post.

  • 0

    Is it possible to test SSO in a non-production environment before pushing it live?

  • 0

    @Jeff, you can test in a sandbox

  • 0

    @Ben Thank you!

  • 0

    I have a question in regards to SSO and remote ticket creation. If we are using the API to create tickets, what do we enter in for the userId if we are using Single Sign-On?

  • 0

    @Paul, there are a variety of mechanisms you can use when authenticating via the API. We recently rolled out support for OAuth, or you can authenticate via a token. Check out Channels > API in the admin menu of your account for more info. If you have questions about setting this up, create a ticket and we can help.

Powered by Zendesk