Zendesk supports Secure Assertion Markup Language (SAML), which lets you provide single sign-on (SSO) access to Zendesk accounts. With SSO, users can sign in once using their company sign-in form to gain access to multiple systems and service providers, including Zendesk products.
You can enable SAML single sign-on only for staff members (admins and agents, including light agents and contributors), only for end users, or for both groups.
As a Zendesk admin, your role consists of enabling the SAML SSO options. See the following topics:
- How SAML SSO for Zendesk works
- Requirements for enabling SAML SSO
- Enabling SAML SSO
- Assigning SAML SSO to users
- Managing users in Zendesk after enabling SAML SSO
- Switching authentication methods
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 all plans. You can also set up single sign-on using JWT remote authentication. See Setting up single sign-on with JWT.
How SAML SSO for Zendesk works
SAML for Zendesk 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 Zendesk accounts.
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 a Zendesk account, they are redirected to your SAML server or service for authentication. Once authenticated, the user is redirected back to your Zendesk account and automatically signed in.
Another supported workflow is giving users access to Zendesk 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 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 the Zendesk Admin Center 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 (including light agents and contributors), 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 as an administrator to enable SAML single sign-on.
To enable SAML single sign-on in Zendesk
- In any product, click the Zendesk Products icon (
) in the top bar, then select Admin Center.
- Click the Security icon (
) in the left sidebar, then click the Single sign-on tab.
- For SAML, click Configure.
- 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.
- Once your SAML SSO configuration is set, click Enabled so you can assign this option to users.
- Click Save.
Assigning SAML SSO to users
After configuring your SAML SSO option, assign this SSO option to end users, staff members (administrators and agents, including light agents and contributors), or both.
- In Admin Center, click the Security icon (
) in the left sidebar.
- Click the Staff members or End users tab and select the External authentication option.
- Select SAML as the Single sign-on (SSO) option in the External authentication section.
For end users, selecting the SSO option automatically deselects the Zendesk Authentication opion if enabled. For staff members, single sign-on might not cover all use cases, so you have a choice to keep both authentication methods. 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 you want all users to only use a single sign-on method, deselect the Zendesk authentication option.
Any Zendesk passwords will be permanently deleted from the account within 24 hours.
- Click Save.
- If you disabled Zendesk passwords, click Advanced > Authentication and select an SSO bypass option.
You can choose whether only the Account owner or all Admins (including the account owner) can be granted access to the account in case the sign-in provider goes 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 Zendesk after enabling SAML SSO
After enabling SAML single sign-on in Zendesk, changes made to users outside Zendesk sync to your Zendesk account. For example, if a user is added to your internal Active Directory or LDAP system, the user is automatically added to your Zendesk account. If a user is deleted in your internal system, the user will no longer be able to sign in to Zendesk However, their account will still exist in Zendesk.
By default, the only user data stored in Zendesk when single-sign on is enabled is the user's given name, surname, and email address. Zendesk does not store passwords. As a result, you should disable any automated email notifications from Zendesk about passwords. See Disabling password notification emails from Zendesk.
To provide a better customer experience, you might want to store more than just the user's name and email address in Zendesk. See Obtaining additional user data.
Disabling password notification emails from Zendesk
When a user is added to a Zendesk 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 Zendesk 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 Zendesk. 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, deselect Also send a welcome e-mail when a new user is created by an agent or admin
- In Allow users to change their passwords, deselect this option.
Obtaining additional user data
The only user data required by Zendesk from your authentication system is the user's given name, surname, and email address. The given name and surname are the only attribute names you should use to capture information about a user's name. 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.
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 end-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: user_field_employee_number . Sending a null value or an empty string in the attribute value will remove any custom field value set in Zendesk Support. |
Zendesk also supports a series of InCommon Federation Attributes to set user attributes as part of the sign in. You should specify the full namespace with the attribute name, not the friendly name, for Federation attributes. Examples:
Friendly name | SAML2 formal name |
---|---|
ou (organization unit) | urn:oid:2.5.4.11 |
displayName | urn:oid:2.16.840.1.113730.3.1.241 |
Switching authentication methods
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.
Topics covered:
Required user data to identify the user being authenticated
When you implement SAML SSO access to Zendesk accounts, you specify certain user data to identify the user being authenticated.
These topics describe the data you need to provide:
Specifying the user's email address in the SAML subject's NameID
You should specify the user's email address in the SAML subject's name ID.
Concept | Where specified | Description | Example value |
---|---|---|---|
<saml:Subject> <saml:NameID> |
Email of the user signing in. Uniquely identifies the user in Zendesk. | stevejobs@apple.com |
Email example:
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">stevejobs@apple.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2014-04-23T21:42:47.412Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
If the givenname and surname attributes aren't provided, then Zendesk will use the username of the email address provided in the <saml:Subject>
<saml:NameID>
element as the name of the user. The first part of an email address before the '@' symbol is the username. If the email's username has a period character in it, then we will use it to parse out a first name and last name. If there is no period character, then the whole username becomes the name of the user in Zendesk.
Email address in <saml:Subject> <saml:NameID> |
Authenticated user’s name in Zendesk |
---|---|
Stanley.Yelnats@example.com | Stanley Yelnats |
Stanleyyelnats@example.com | Stanleyyelnats |
Specifying two required user attributes in the SAML assertion
When specifying the user attributes, givenname and surname, you must specify the attributes with the full namespace. For example: where friendly name might be 'surname', the actual value you need to use for the attribute is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
Concept | Attribute | Description | Example value |
---|---|---|---|
first name | givenname | The given name of this user. You must specify the full namespace for this attribute. |
|
last name | surname | The surname of this user. A user in Zendesk is created or updated in accordance with this user's given name and surname. See example below. You must specify the full namespace for this attribute. |
|
Given name and surname example:
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<saml:AttributeValue xsi:type="xs:anyType">James</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<saml:AttributeValue xsi:type="xs:anyType">Dietrich</saml:AttributeValue>
</saml:Attribute>
Zendesk supports additional user attributes. See Obtaining additional user data for a list of supported attributes. Talk to your Zendesk Support admin about their data requirements in Support.
Configuring the identity provider for Zendesk
Attribute | Value |
---|---|
entityID | https://yoursubdomain.zendesk.com |
AudienceRestriction | yoursubdomain.zendesk.com |
where your_subdomain is the Zendesk Support subdomain. If unsure of the subdomain, ask your Zendesk admin.
Zendesk enforces the AudienceRestriction
attribute.
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://yoursubdomain.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.
Attribute | Description |
---|---|
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. |
Attribute | Description |
---|---|
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:
https://www.yourdomain.com/user/signout/?email=&external_id=
Troubleshooting the SAML configuration for Zendesk
Here is Zendesk's SAML 2.0 metadata:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EntityDescriptor entityID="yoursubdomain.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://yoursubdomain.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://yoursubdomain.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 above.
Required user attributes in the SAML assertion
Attribute | Mandatory | Description |
---|---|---|
Yes | Email of the user being signed in, used to uniquely identify the user record in Zendesk. | |
name | Yes | The name of this user. The user in Zendesk will be created or updated in accordance with this. |
organization | No | Name or id of an organization to add the user to. |
tags | No | This is a JSON array of tags to set on the user. These tags will replace any other tags that may exist in the user's profile. |
remote_photo_url | No | URL for a photo to set on the user profile. |
About IP ranges [otherprops="draft"]
"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 sign-in form. To route all requests through remote authentication, leave this blank. An IP range is in the format n.n.n.n, where n is a number or an asterisk (*) wild card. Separate multiple IP ranges with a space. Your current IP address is: 209.119.38.228 " < Explain how these are used > Use case?
Supported SAML providers and configuration examples [otherprops="draft"]
Some SAML providers do something good and we support them. Here are other supported examples:
- Setting up Okta single sign-on
- Setting up OneLogin single sign-on
- Microsoft (coming soon)
57 Comments
In particular, for folks who are using a SAML provider to provision user accounts in Zendesk, it would be really nice to call out to admins here that if you do this you also need to ensure that in Zendesk the "Also send a welcome e-mail when a new user is created by an agent or admin" and the "Allow users to change their passwords" checkboxes are both unchecked in Customers section of the Zendesk admin console.
You could probably also call this info out on the Customers section of the Zendesk admin console.
Otherwise every user created by provisioning from a SAML provider will get an e-mail notifying them to verify their e-mail address and create a username and password.
Speaking from experience this would have been nice to know.
Hey Alan!
Thanks for bringing that up! You make a good point. I'm going to pass this along to our Documentation team to see if we can make the docs on this more clear.
Hi guys, as James Peterson mentioned above, the only official, supported way to log a user out is by sending them to the access/logout endpoint. As you have noticed, SLO is not officially supported. One possible workaround might be to set your SSO logout URL to your IDP's logout endpoint, which will redirect the user there after ZD logout and the IDP can take it from there (keeping in mind that the IDP should not redirect back to access/logout, or a redirect loop might occur!)
As for the issue at hand, I highly recommend letting our product team know about your issue and why you would like to see this functionality in the future. You can do this in our product feedback forum: https://support.zendesk.com/hc/en-us/community/topics/200132066-Product-feedback
Thanks!
Sam
The original post about SAML was written in 2011. I'm hoping for an update. Does ZenDesk support true-multilateral federation? This means consuming central federation metadata (such as provided by one of the many national federations here (https://refeds.org/federations/federations-map); discovery for users where there might be hundreds of Identity Providers to choose from (https://discovery.refeds.org/guide/).
Anyone have success with ZenDesk and multilateral federations like InCommon? Anyone? Bueller?
Hey Jcwk! Sorry we didn't get back to you on this sooner. I'm following up to see what I can find out. :)
Hi Jcwk!
Zendesk does support InCommon Federation Attributes to set user attributes as part of the sign in process; for example, you can set up the ou (organization unit), or the displayName. You can find more details about these attributes on this page - InCommon Federation Attribute Summary.
Please let us know if this helps!
Alexander, That's great to hear. Before we can get to attribute release, we need to know if the ZenDesk service provider (SP) is able to consume multi-entity SAML metadata. Most international federations produce an aggregate of IdPs and SPs. Here's an example of InCommon's: https://spaces.internet2.edu/display/InCFederation/Metadata+Consumption . Does ZenDesk consume multi-entity SAML metadata and provide a way (like a discovery service linked to in my comment above) for more than just 3 or 4 Identity Provider choices? Thanks so far!
@Jcwk - Thank you for your additional questions! I have created this ticket #1675584 to further check your specific workflow. Would it be OK to join us in the ticket? Thank you very much!
Question about organization IDs. Based on the documentation organization/organizations explicitly state that external_id is not supported when syncing users to orgs based on their SAML response. However, it is not clear if external_id does or does not work with organization_id/organization_ids.
Obviously what we would most prefer is to join users based on external_id, otherwise, what is the point and purpose of having the external_id on the org in the first place, if we cannot use it to join up users to orgs, based on the IDs we know on our side. If external_id is not supported in any SAML field, then we have to make sure we keep and store Zendesk IDs on our side and keep them in sync with our known IDs for the orgs and this is rather suboptimal, for hopefully obvious reasons.
Hoping that the answer is external_id can in fact be referenced in the organization_id field, so we can sync up users to IDs based on our known set of org IDs, internally. If not, then we need to scope out how much effort it will take for us to store/sync with Zendesk org IDs as well.
Hi there Robert-
Thanks for writing in, and please feel free to correct me if I misunderstood. Based on what I am reading, it sounds like the path of least resistance here would be to first create these organizations in Zendesk with your system's external_id values, to then retrieve the organization_id value Zendesk generates for use in a given SAML payload. You outlined it yourself more or less, and I understand the reasoning for looking for a workaround
To be 99.99% sure I tested with some simple cURL calls to be sure there wasn't a way around this (at least that I could find).
Another item of note is that if the org doesn't exist to begin with we will scrap that payload attribute, more reason to simply create the organizations with no members to begin with. Then, as your users log in, they should be added automatically, or added should you bulk import/update. This choice is one of what will scale better based on your own needs.
Lastly, should the value of the external_ID in your own system change, it can be updated quite easily. More on that here in our REST API documentation.
Joseph,
Thanks for the reply, and let me try to clarify slightly...
As far as Organization go, sure assume we have already imported and loaded all our Orgs, with external_id values specified, that has already been completed.
Given that, from what I understand given the documentation, the SAML payload can reference the Org(s) a user belongs to and that can be specified in either the organization OR the organization_id field.
Am I correct in assuming that the organization_id field cannot reference the external_id field, in order to sync/join up the User to their Organizations. If this is a correct assumption, then yes we need to do some work on our side... the docs for organization field explicitly states no external_id, but does organization_id disallow or does it allow external_id, it's not stated.
If external_id can be used in neither organization nor organization_id, and we always need name (which is brittle and subject to change) or it has to be the internally assigned Zendesk ID... then yes we need to do some work to store that / align that somehow. But hoping we can somehow use external_id. If not, so be it, we'll sort it out. Just want to be sure I have my facts straight before we do any potentially unnecessary work.
In "Zendesk expects a SAML assertion that looks like this", the example SAML seems to be broken at the moment. The samlp:StatusCode is the last element shown, samlp:Status is not closed and there is no Assertion at all.
Could you fix / update this SAML snippet, please?
Hey Jarkko - good eye! I'm going to ask our Documentation team to update the snippet. Thank you so much for noticing it.
Hi, I believe the example SAML assertion/response is incomplete or inaccurate. There is no <samlp:Assertion> element included in the example, which doesn't seem right. Hoping to get an update to clarify what a real SAML response should look like? In addition are their any required attribute claims?
Hi Tim! I've created the following ticket: #3104525 to check this further for you. Please join me in that ticket. Thank you!
Hi there! Thanks for the elaborate tutorial on setting this up. I've been receiving an error when trying to use Okta as my IdP. I see that I'm logged out as soon as I provide my details on the Okta Login Page and click on Login. I tried debugging the request with OneLogin's SAML Developer Tools, but it tells me that the Issuer param in Zendesk's SAML Request is Invalid.
Can someone please guide me as to where am I going wrong ?
Welcome to the Community, Kartik! I'm sorry for the delayed response here!
I'm going to see if I can find somebody to answer this for you, since I'm not very well versed in SAML. Stand by!
@ Kartik,
The issue you raised here would be best investigated via a support ticket. I have created a support ticket so that we may collect a few more details from you, most of which are quite sensitive in nature that we would certainly not want to post here.
I look forward to joining you in your support ticket!
I tried to use organization_id to associate a user with an organization. It didn't work, but using organization_ids does work.
First i want to join Robert comment about external_ids - this feature looks quite mandatory when provisioning users through SAML assertion , which i believe most customer will want .
second i want to join others comments about the SAML response example.
there are fields in the example , which do not exist in the table , e.g givenName and surName
also i have tried to set the role and custom_role_id , and got redirected to the login page.
and last about the redirect loop - we also suffer from this , and i think that Zendesk should not
add SAMLRequest to the redirection cause this one causes the whole loop.
Shlomi
Thanks to Shlomi, infact i have struglled for this external id how to pass where to pass etc etc; now finally sso is done by figuring out the https://d16cvnquvjw7pr.cloudfront.net/resources/documentation/Zendesk_Admin_Guide.pdf by setting the attribute <saml2:Attribute Name="external_id"><saml2:AttributeValue>your unique identifier (typically GUID)</saml2:AttributeValue></saml2:Attribute>.......
but i was figuring out the logout and its seems zendesk supports rich saml logout which I need to implement: can you please let me know whether logout is SP initiated or IDP initiated;
if it is SP init then why I am getting 404 when clcking my mvc app link zendesk/logout (and this link aspects post parameter)
if it is IDP init then how I will sign the logout request the post to this url because my customer is using zendesk and does not share certificate for signing.
any help would be greatly appreciated...
Sam Michaels thanks for the logout implementation hint. but when we are hitting our SAML provider (who is using zendesk enterprise setup) we are getting "The requested resource could not be found."
Can you help me how to properly call logout link.
We are able to do sso but slo is being tricky. the SSO is happenning on IDP initiated sending SAML response to zendesk ACS (HttpPost) link with external_id. The logout is also HttpPost link but what ever (LogoutRequest signed, unsigned, external_id order in attribute etc etc) is send it always say 404.
Any help / guidance would be very helpful.
Hi Saurabh! I've created the support ticket #3774586 to check this with you. Please join me in that ticket. Thank you!
Hi all!
So, when everything goes well, there is a SAML assertion returned to ZenDesk, but what happens if there is an error that the authentication provider can't deal with? Is there such a thing as a SAML Error / Exception?
We are having this situation: Users sign up and get a verification e-mail, but not all check their mail and try to sign in before having verified their user.
When they do this, there is an error message from the authentication provider saying:
This is not presented to the user (like a "wrong e-mail or password" message is), instead, the session is redirected to ZenDesk, with the error in the URL. Then, as soon as ZenDesk see that the user is not logged in, the session is again redirected to the authentication provider, which presents the user with the regular login-screen, without further notice of the error. - So the error message is never presented to the user. According to the authentication provider, this is how the OAuth 2.0 specification, section 1.7 and 5.2 requires it to be.
Is this correct? Does ZenDesk have a way of displaying error messages from SAML? Should they?
Hi Jorgen!
Thanks for your post!
It sounds like most of the issues in the flow are outside of Zendesk, as the authentication process is determined by the SAML provider. As such, it makes it relatively difficult to confirm or deny the normalcy of the behavior in question.
My suggestion is to create a ticket with a HAR file of the flow so we can see timestamps and errors in the order they occur with the navigation steps in order:
https://support.zendesk.com/hc/en-us/articles/204410413-Generating-a-HAR-file-for-troubleshooting
This would at least provide us with a starting point to troubleshoot further.
Hopefully this proves helpful!
Hi Joe!
Thanks for your feedback. I probably gave too much information in my message, but what I really wanted to know was this: Does ZenDesk have a way of receiving error message from SAML and displaying them?
(The authentication provider is saying that the OAuth 2.0 spec is requiring errors to be handled by redirects, back to the app, with the error message. However, this seems a little strange, as there are other error messages that are treated by the authentication provider, so I am trying to understand what the spec says, and what the possibilities are, so I can direct my support-ticket to the right place.)
Kind regards,
Jørgen
Please sign in to leave a comment.