How would you feel if you were in the shoes of LinkedIn’s CISO in the morning of June 6^th 2012?

In case you are wondering what happened on that day, check out this link. It describes one of the largest identity theft that has ever happened. Actually it was not the CISO but rather LinkedIn’s SVP of operations in charge of security. Either way, I sure wouldn’t want to be in his shoes.

For quite a while, I have been wondering whether it was possible to create a product or a service that would keep its users details absolutely protected. And when I say “absolutely”, I mean that there will be no way to steal this data. For example – could Google design Gmail in such a way that it would be practically impossible to get Gmail users details?

If the answer for this question is relevant for you, you may find this post helpful.

Up until ten years ago, when building a product, matters such as login, identification and authorizations weren’t a big issue. At most, we used a reasonable framework for session management and wrote proprietary code to implement the user management system, the authentication and the authorization processes.

But something has been changed in recent years. The number and type of attacks have grown exponentially. In fact, today anyone can download and run programs like Acunetix, Webinspect and others and start hacking away. Hacking has become a business for all intents and purposes and, as the PWC report of 2013 shows, personal details or applications vulnerabilities are the currency which fuels a growing underground industry. On top of that, the Cloud and SaaS have further changed the equation. All of a sudden, many systems are not located behind the corporate firewall any longer. They have to communicate with each other, and that makes them even more vulnerable.

Since attacks are profitable and we are exposed to so many of them, then protecting the user’s details becomes a challenging task. Even if you follow strict coding best practices and do your best to protect your users DB, the popular belief is that a determined hacker will find a way to get them; much like a determined burglar can get through any lock.

But what if your users’ details are not there? It is impossible to steal what’s not there and it is very easy to protect nothing. I mean, who would want to break into an empty safe?

We might think that using directory services (e.g. active directory and LDAP) would answer this. But what I saw that usually happens is that an application would copy the users data from the directory into its own private DB and manage it on its own. As the product still keeps an internal users DB – it is still possible to hack this information.

Creating a system without users is not that simple. Luckily someone has already solved most of the problem for us. Technologies such as SSO, federation, and IDaaS can be harnessed to get this result. But before we continue, let’s put some order in these terms:

• SSO – This is a super-term, referring to a system which allows the user to identify himself only once (e.g. by typing username / password) and then be able to use multiple systems without re-login. So there is no need to remember and type many passwords and the echo-system seems to be integrated as you can pass from one service to the other.
  There are many SSO products.  The leading among them come from large software providers such as CA SiteMinder, Oracle ESSO, IBM Tivoli and others.
• Federation – Federation is a special flavor of SSO. The main difference is that the person, who logs in, does it through a trusted external server, so you can’t access his or her details (e.g. you don’t know his password). Popular products in this category include CA SiteMinder, Oracle OIF, Ping and others, to which you connect through protocols such as SAML, OpenID, OAUTH and OpenIDConnect.
• IDaaS – It’s easy to think of IDaaS as federation in a Cloud, so the server responsible for the user authentication is an external SaaS service. Sometimes it actually holds the user’s details and sometimes it is only a proxy, relaying the authentication to a 3^rd party. Recently, IDaaS services from Salesforce, Ping and Google have become more popular.

As federation “exports” the responsibility of running the user authentication to an external service, it brings us one step closer towards our goal. However, with federation as well as with SSO, most products would keep their own users DB and run an aliasing process upon login. Needless to say, if a product still holds such local DB (and that is usually the case), it is not good enough. If we want to prevent identity leakage, our product has to be able to work without any “self” users DB, meaning:

• The users table is not part of our product, so the authentication is run by the federation server.
• The federation server is also responsible to send us the user authorizations and any other information our product needs (for example, is it a user with admin rights or just a regular user).
• The federation server has to allow us to manage our users (creating, updating, deleting, changing passwords, reporting, auditing etc.). Recently standards such as SCIM are becoming more popular.
• Last, but not least – we assume the customer who installs our product is ready to configure it in a federated environment.

Putting it all together

The advantages of the above approach are obvious – no details to steal. Next time a large hacking scandal hits the headlines you can sit back and relax. Your products are safe. Also, federation servers and IDaaS services come from large manufacturers who spend lots of time and effort in securing their sensitive products. They are supposed to know how to do it much better than you.

The risks are obvious as well – exporting sensitive information such as user’s details is a potential risk. Data-at-motion must be secured and you have to protect yourself from threats such as man-in-the-middle and others. Also, now your product performance and availability relies on a third party component. We also need to remember that not every federation solution may suit our needs. It has to support authorizations management, reporting, provisioning and auditing.

To sum things up, this approach is good for products being installed in small or medium-size organizations that don’t have the expertise or resources to securely manage their user base identities. These organizations may find IDaaS suitable. It may also work well for large organizations that have incorporated federation servers and plan to integrate it with their systems. Nevertheless, other customers will always expect out-of-the-box solutions, without the need to configure or connect to external servers. In the near future, you will probably need to provide dual installation modes – a built- in user management system, as well as the option of integrating with federation servers or IDaaS services.

Do you know federation tools which can provide advanced user management services, as well as identification and authorization capabilities? For your product – would it work to plan for a “userless” installation or must you use the standard solution? Maybe you could suggest a different approach? Please share your thoughts and add your comments below.

Good luck!
Ilan