Freshdesk SSO

Martin, Brandon L martinb at
Mon Aug 10 13:36:45 EDT 2015


Thank you for all your advice. I was able to successfully authenticate with the Freshdesk SSO!

However, I can't fully authenticate for my user attributes are encrypted and Freshdesk is not decrypting them before processing the information.

In my logs I can see I am getting the correct data from my ldap data connector. I then send the data to Freshdesk with this RelyingParty:

<bean parent="RelyingPartyByName" c:relyingPartyIds="">

            <property name="profileConfigurations">


                    <bean parent="SAML2.SSO" p:encryptAssertions="false" />




I am only able to authenticate with encryptAssertions set to false.

In my logs I am sending this data:




Then in the Freshdesk interface after I log in, it says my email is AAdzZWNyZXQxWjx


I've tried several solutions from the internet without the result changing. From toying with md:NameIDFormat in the metadata to trying different options in the relaying party.

Thank you

Brandon Martin

martinb at

Peninsula School District

Data Integration Analyst

Ext: 3712

From: users <users-bounces at> on behalf of Nate Klingenstein <ndk at>
Sent: Saturday, August 8, 2015 11:02 PM
To: Shib Users
Subject: Re: Freshdesk SSO


That helps tremendously. I have been testing with the fingerprint of my encryption certificate. In the service it says the SHA-1 is the encryption and signing certificate.

It's possible to use different certificates for encryption and signature.  It wasn't a common case prior to the release of IdPv3, but I think they were probably trying to accommodate that.  As an IdP, your signing certificate is almost always the relevant one.

Does this mean in the metadata I include both xml objects to link signature and encryption as the same values as my X.509 signing certificate?

If I were to guess and reword this as "does this mean that I should enter my signing certificate's SHA-1 hash into the fields on their webpage", then I would say yes.  I'm not quite sure how to interpret your question as stated.

In other words, I tell my metadata-less friends about my encryption and singing certificates but they are both actually the cat of my signing certificate.

Well, the hash isn't just the entire base64-encoded printed raw value.  It's a specific field.  You can find that field using tools like openssl.

My browser certificate will be different than my IDP certificate. I am behind a load balancer that provides https certs, is this a problem?

No, generally it's a good thing because it gives you more flexibility in management of each certificate and won't need to roll over your IdP certificate with frequency.  It's a deployment decision, though.

Take care,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list