Integration with Zendesk SP

[Hwei Chan]

Hi Peter,

Thanks for your response.

Sorry, should have mentioned what I did try!

So far I've:

1. set the SAML SSO URL to 
https://idp-dev.powergenius.net/idp/profile/SAML2/Redirect/SSO

2. set the SHA256 fingerprint as you've described

3. made added the metadata to a local file and configured it with a 
FilesystemMetadataProvider

4. updated attribute-resolver.xml and attribute-filter.xml with some 
general attributes, eg, mail, displayName, uid (not specifically 
targeted for Zendesk like NameID of type emailAddress)

5. set idp.encryption.optional = true

The error I'm getting is:

2017-04-08 11:00:18,043 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler:  No metadata returned for https://xxxxxx.zendesk.com in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol
2017-04-08 11:00:18,047 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID https://xxxxxx.zendesk.com)
2017-04-08 11:00:18,049 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration

I'd appreciate any suggestions / pointers for the above error.

In the meantime, I'll try the NameID config and see if that makes a 
difference.

Thanks again!

Regards,

Hwei


On 08/04/17 22:45, Peter Schober wrote:
> * 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