Has anyone here used SSO (single sign-on) with a SaaS app? I’m asking from either side - the SaaS vendor or the customer.
Is there any approach in particular that you’d recommend? Did you encounter any frustrations that could have been avoided with a different approach?
I’m keen to hear any tips about how you added SSO.
(I assume when you say SSO you mean “users of other services - Facebook, Twitter, … - can login into your application”, not “I have 2+ applications and want to share users between them”.)
Use OAuth which is supported by everyone now. OpenID is out of use now.
The main annoying thing is that every provider has their own little quirks. However many libraries for OAuth support already deal with these differences, making them invisible for you.
I assume when you say SSO you mean…
Thanks for the answer. It helps to illustrate that simply requesting SSO is ambiguous.
Adding SSO to Feature Upvote is currently our most highly requested feature. I suspect different customers want different things which they are all calling SSO.
I wrote to a specific customer who has been asking for SSO to find out more about what they wanted. It turns out they want to be able to integrate our SaaS’s authentication with their existing Active Directory server using the SAML protocol.
The way we handled this at Roadmap was to have the portal embedded into their own app (web or mobile).
Maybe something you could consider instead of SSO @SteveMcLeod since we’re kind of on the ~same grand market.
Instead of handling authentication from our end via SSO, our users can have their roadmap and ideas portal straight into their web application, behind their sign in flow.
That was done to postpone implementing SSO as far as possible I must admit 
Which we’re also starting to investigate. But at least we saved 1.5 year.
Ah…that does sound like a much easier way to achieve SSO! A benefit of an embedded widget I hadn’t thought of before.
By coincidence, this is in my TODO list as well. I just fired a short email to my clients security folks to ask them what are the required steps.
My understanding the steps are as follows:
It looks much better that the older systems when your server and the IM would have to talk to each other directly, which is not easy over the internet - AD is behind the firewall.
My use-case is simpler than yours because my users are only coming from inside of the corp network, so I don’t have to decide how to authenticate the users, but this is minor point.
I’ll let you know when I get an answer.
Hmm… doesn’t this mean that the widget is not protected? And that I can call that widget from any point in the world (or at least from any point within the corp network) and do whatever I want?
Not at all, it just means that instead of implementing SSO I built a fully embeddable widget.
You can call the widget from anywhere in the world, well of course, that’s the point of a widget.
When you say do whatever you want. What do you want to do more than what a widget exposes? Of course you can call the endpoints and what not, they are allowing CORS.
If you’re talking about simulating fake like and what not, just like Feature Upvote there’s throttling and filtering etc.
Not sure what you’re referring to. Happy to discuss how I implemented this if you have more questions. The goal of a widget, like Intercom’s for example is to be “public”.
Our users can wildcard domain that can embed the widget, of course.
Hope that answer the question.
Yeah, I may be missing something.
OK, suppose there is an internal corp portal. I’ve logged into it, and I’m on its page. The widget is loaded into a block on that page - from another server, I assume.
Security folks told me that they do not use AD IdP (Identity Provider) for that, but Siteminder IdP. The protocol however is the same: SAML 2.0 Federated Services.
One correction they made to my idea of how it works is that IdP won’t accept authentication requests from just any application, because it creates a security risk: “Otherwise one application can get a SAML token and then send it to another web application.” As the result, the application has to be registered with IdP. Among other things, this step involves configuration what user attributes are sent from IdP to application (user FN, LN, id, whatnot).
When the portal embed the widget they pass identification metric to the load function, exactly like Intercom receive current logged in user.
This is the responsibility of the “embedder”, they should embed only behind their own authentication mechanism.
So… if I embed the widget to a page on my own server within the corp network, I can pass any “identification metric” to it?
yes, why would someone do this kind of things, plus, the admin can whitlist certain domain where the widget can be embedded, so if you don’t want anyone to embed your widget, you specify which domain are allowed to embed
Unhappy employees do all kinds of stupid, malicious and backstabbing things. Experienced that first-hand.
Besides, the purpose of security is leave nothing to a good will of any actors; if a resource is secure, even if I want to harm it, I cannot.
This can help. However, in the context of corp networks, the hostnames and IPs are not as stable as the internet-facing ones.
The bottom line - if the client wants authentication against AD, this is their corp security standard, and to convince them to deviate from it is not an easy task.
On the other hand, a support for SAML Auth takes a SAML library in the HTTP filter (or whatever module can intercept the requests in your language of choice) and a bit of configuration. The application logic is not affected.
When you use an embeddable widget as a surrogate for SSO, the security usually works like this:
AD / SAML SSO should be done with a library i think. Doing this yourself would be much work (and requires much security knowledge / care of edge cases).
Using the SAML protocol and Azure Active Directory as the “identity provider”, I’ve got a proof of concept of SSO working. I’m surprised by how straightforward it was. It is quite elegant too.
For now, I’m only going to offer Azure Active Directory integration.
I think the real challenge will be how to make it easy for my customers to set up and troubleshoot.
And edge cases, as mentioned by @unboot. I’m sure to run into edge cases. As per @unboot’s suggestion, I’m using SAML SSO libraries.
Usually the IT team of a customer will implement SSO, and they’ll have experience. These are usually not your app users, but the IT staff.
While I agree that a widget can be secured, the steps that you list are essentially re-doing of SAML protocol, just poorly
Yes, SAML Auth for Web is surprisingly simple, both to implement and troubleshoot.
If your SAML works for one IdP, it should work for any other too - provided that your application is registered to that IdP. In other words, that customer who wants the support for their AD IdP? They need to configure their IdP to accept your app requests, and on your side you just need to configure their URL - minimum work, as I see it.
Just in case, OAuth works only for authorization, for authentication of a user you need OpenID Connect, which is built on top of OAuth2 protocol. Some more on differences between them are here.