A guest blog post by Christiaan Brand, CTO at Entersekt, Cape Town
Managing user identities in a corporate setting is often pretty challenging — even more so if the company is expanding rapidly and trying to integrate some of the best Cloud-hosted tools into their environment.
I’m Christiaan Brand, the CTO for Entersekt, a young, fast growing software security company based in Cape Town, South Africa. Among my other duties, I’m responsible for our general user control ecosystem. One of the first things you have to establish for a company of any size is an authoritative trust source against which users can authenticate. I believe this is something we did right — right from the beginning when we were only the four founders and were only accessing email, our workstations and our one Fedora server. This has allowed us to scale effortlessly to where we are today: more than 60 geographically distributed users, multiple internal and external applications – all with one single user information store.
I hear of so many companies where the logins to different systems are internally shared by employees, written down on sticky notes, stored inside applications responsible for managing passwords and other systems, which simply does not scale. It’s not rocket science, but it does take a bit of planning to get it right.
The case for SSO
When I started this process, we decided on Microsoft Active Directory for our organization’s user store. Now don’t get me wrong, almost all of our production services run on some flavour of Linux, and most of our applications are either J2EE or PHP–based, or even run in the Cloud. But, there are very few on-premises solutions out there that can beat the robustness and ease-of-use of the combination of Microsoft’s AD, Exchange, Lync and SharePoint. This combination allows us to be in complete control of all of our data. Due to the regulatory requirements of the territories in which we operate we can’t store all emails and other sensitive customer data somewhere in the “Cloud” and, besides, in some cases it’s still more cost effective to simply manage data on site (http://www.wired.com/wiredenterprise/2013/08/memsql-and-amazon/) not to mention the freedom it gives when wanting to integrate and make it interoperate with other solutions. But enough promotion of Bill.
Every once in a while you come across a great company with a great product that does not really make a whole lot of sense to try and run on-premises. One such company is Small Improvements. I was intrigued by it ever since Johan Prinsloo, our HR guy, showed me the tools. Being an engineer by trade, I don’t often get that excited by the “softer” side of a software company, but this looked pretty cool. It even looked like it had support for SAML. That made me even happier — there’s nothing more frustrating than a company offering you services in the cloud and then expecting your users to manage yet ANOTHER pair of login credentials. By integrating it into our own SAML IdP (Identity Provider – the SAML system that does authentication on behalf of Service Providers) our users can use their existing AD credentials to sign into Small Improvements. Of course, you don’t have to be using AD as your backend identity store — pretty much any central list of user identities will do — but in the next section I will explain how to use simplesamlphp and the LDAP-connector to integrate into AD’s LDAP provider.
SimpleSAMLphp is an open-source and very lightweight, easy to use SAML IdP and SP. If you want to get started with being a SAML Identity Provider for your organization I’d recommend that you head over to http://simplesamlphp.org/
It’s fairly easy to configure everything to work with Small Improvements. The detailed documentation can be found over here: https://www.small-improvements.com/documentation/simplesamlphp. Enjoy!