Integration with Zendesk SP

Peter Schober peter.schober at univie.ac.at
Sat Apr 8 06:45:15 EDT 2017


* Hwei Chan <hwei at nextidea.co.nz> [2017-04-08 04:45]:
> The aim is to get SSO working from Zendesk (and a few other third party
> services) to our Shibboleth IdP instance.
[...]
> However, I'm having trouble getting the setup for Zendesk working.

You don't mention what you did specifically, nor what error you got.

> https://support.zendesk.com/hc/en-us/articles/203663676
> 
> They seem to require at least:
> 
> * Remote login URL for the SAML server (Shibboleth)

There's no mention of the (protocol) binding to be used for requests
sent to the IDP (unless I overlooked those; the ones they mention are
about the response to the SP, I think), but so you could try Redirect
and then POST. For a typical Shib IDP those URLs would be:
https://idp.example.org/idp/profile/SAML2/Redirect/SSO
or
https://idp.example.org/idp/profile/SAML2/POST/SSO

> * SHA2 fingerprint for the SAML certificate from the SAML server

openssl x509 -noout -fingerprint -sha256 -in credentials/idp-signing.crt


>From the looks of it (though they don't mention it explicitly in the
text) they also expect you to send a NameID of type email address for
the subject. The Shib wiki explains how to do this, but the short
version would be adding this within the
shibboleth.SAML2NameIDGenerators list in your conf/saml-nameid.xml
(assuing a supported IDP release):

  <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
    p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
    p:attributeSourceIds="#{ {'mail'} }" />

Then also release the mail attribute to that SP in your
attribute-filter.xml. The metadata they publish for the SP already has
a NameIDFormat element, so that should be sufficient to make email the
preferred NameID format.

Whether doing/sending that is a hard requirement I can't say.

> The only thing I've found regarding the Zendesk SP metadata is:

Well, then make the required changes to it and configure the IDP to
load that metadata from a local file, e.g. by uncommenting the
<MetadataProvider id="LocalMetadata"> element in your
conf/metadata-providers.xml and adding any local SPs to the
metadataFile specified there. 

> The other SPs I've tried requires the IdP's metadata (which Zendesk
> doesn't seem to ask for) and the other SPs metadata seem to contain
> a lot more info then the above.

Since the SP does not provide you with a key suitable for encryption
all data sent will only be protected by TLS, not by xmlenc. That means
you may also need to convince the IDP to release attributes even
though they're not encrypted (with a relying party override, or
settings this generally for the whole IDP).

Speaking of attributes: Unless you intend to only send "ou" and/or
"displayName" (the only attributes they seem to accept URI naming for)
you'll have to configure your attribute-resolver.xml with "basic"
attribute names, for all attributes you intend to send them.

> I've tried a couple of things but none of them have worked.

What things specifically?
How did they not work?

-peter


More information about the users mailing list