Single sign-on for serious startups
ClauseBase is legal technology that allows lawyers and inhouse legal counsel to quickly draft complex contracts using intelligent clauses that act as building blocks.
Even though we offer powerful software with a certain learning curve, we have ensured from the outset that legal experts can use the software without any help of their IT department — all that is required, is a modern browser.
This way, we can avoid the trap of requiring legal experts to cooperate with IT experts in order to automate their contracts since, time and time again, we have seen such cooperation going haywire: IT experts are typically not interested in (learning all the ins and outs of) legal fine print, and legal experts do not want to outsource one of their core tasks.
This setup has served us well so far with our early adopters. However, as our userbase is growing, our software is also getting increasingly used in large law firms and large corporations. One of the typical requirements of such companies is to offer single sign-on (SSO), not only to avoid the hassle of juggling with usernames and (forgotten) password, but also to increase security. The central idea behind SSO is that users get authenticated in a central location, and then inform third-party services that a certain user should — or should no longer — be allowed to login.
While we remain convinced that the core contract automation activity should remain with legal experts, requirements such as SSO obviously involve IT departments and heterogenous environments. And this is where things become complex for startups that want to remain focused on their core offering.
The SSO landscape
At its core, SSO is actually not so difficult to implement. Several protocols exist, among which SAML is the most widely used. SAML involves the exchange of several XML messages with the so-called “identity provider”, i.e. the central instance that authenticates a company’s users.
However, even merely reading about SSO and experimenting with all the different technologies involved will quickly drag a startup away from its core offering. Before you know it, you are setting up an Azure Active Directory instance or looking at complex and expensive corporate software such as Okta, or open source technologies such as Keycloak and Gluu, with a dizzying number of options, and where SSO is just a small part of the entire offering.
Would an easier or more targeted solution exist? When googling around for for SSO and Clojure (the programming language used by ClauseBase), we quickly found a library that promised to implement SAML-based SSO, but it had not been updated in over 5 years. A fork of this project was more up-to-date but not heavily used, with few documentation, and with the suggestion to consider a Java-based alternative that once again seemed like some serious overkill for our needs. The final nail in the coffin was offered by a post on the Clojure Reddit channel, which pointed out that — even when everything is properly implemented from a technical perspective — you can expect some issues in day-to-day practical operations when connecting to your customers, as there exist many small incompatibilities between the various identity providers, who also tend to introduce small breaking changes over time.
Luckily, that Reddit post also pointed to several possible solutions, one of them involving Osso, which we eventually gave a try.
Our implementation experience
Using Osso, we implemented a full-fledged SSO solution in about three days of work. About 80% of this work actually consisted of ancillary work that was unrelated to Osso itself, but was caused by the complexity of our platform.
We already offered multiple ways to sign into our platform (traditional username/password login; two-factor authentication login; login through a short-lived URLs through the API; login through an anonymous URL; etc.) and adding SSO to this mix required some refactoring of our Clojure code base. Moreover, Osso relies on OAuth2, but Clojure’s standard OAuth2 library is still at an early stage and required some modifications, so we eventually ended up writing some of these parts ourselves, with some inspiration by Osso’s developers.
With a more straightforward technology stack (e.g., NodeJS), Osso’s claim of being able to implement SSO in a few hours is probably completely justified, particularly when Heroku can be used for hosting, or when one of Osso’s paid plans is used.
Data protection issues
While unrelated to SSO itself, it may be interesting to point out one of Osso’s major strengths: it is completely open source and can thus be self-hosted.
There are some other “easy” SSO solutions that offer a hosted solution as one of their paid plans. Unfortunately, for ClauseBase, this was not a viable solution, in light of our typical audience of law firms and inhouse legal counsel. Those legal experts may not be front-runners in technology, but they are very, very aware of the strict requirements of European data protection legislation (GDPR). Before founding ClauseBase, I used to be a technology lawyer myself, and in that role I have spent countless hours arguing for or against the alleged (in)compatibility of US hosted solutions with European legislation.
Indeed, even when data is hosted within a European data centre, there exist (theoretical) possibilities that US-based hosting providers would be forced to hand over data to foreign governments, or would uphold that internal data security policies or even legal data transfer mechanisms are ruled invalid by the EU’s highest courts.
Convincing legal experts to adopt legal technology is already hard, so to avoid further discussions (about data transfer), we decided at the outset to only let EU companies near our hosted data. In other words, no Heroku and no Amazon, and self-hosting our SSO solution on a Linux server in a European data centre.
Final words
All in all, we are extremely happy with Osso. What threatened to become a painful journey that would lead us astray, turned out to be a super smooth and inexpensive solution.
That smoothness even extended to our customers, who really loved a small nifty feature of Osso: a nice PDF that describes in an easy-to-follow way which parameters have to be completed at their end (e.g., within Azure or Okta) in order to connect to ClauseBase’s SSO instance.
