Identity federation is a concept that emerged through the increasing use of Cloud applications and its collateral effects. Since people started to use apps that were not managed by the company directly, it really twisted the way security people looked at their field: it had to be rethought.
Beforehand, security was managed like a castle. Roughly that means: the good guys inside, the bad ones outside and a firewall between those two. Today, companies’ resources are based on the Cloud so anybody can come, knock at the door and get access to corporate data. How can you fill the gap?
Cloud app security systems vary from an app to another
Corporate resources that used to be inside the company are now hosted outside. Say you want to use salesforce.com: how can a company control how its employees are accessing this particular app? It is not its property and thus Salesforce has its own security protocols the company will have to cope with:
- How do users login? For example, does the app use the SAML protocol or is it OpenID?
- How do you grant people access to such apps and not to others? And how do you remove them when they’re gone?
- How do you get access to logs?
Thus, for each Cloud application, companies need to understand how it works and how to interact with it. Needless to say it is ok when there are a couple of apps but when there are a hundred? That’s this situation that led to the concept of identity federation.
identity federation or how to segment a company’s population
Facing this situation, there’s a clear will from users to get away from companies’ apps. A bit like BYOD, people are tired to use out-of-date apps that don’t work as fast and efficiently as the ones they could use in the Cloud.
Consumerization of IT has led to a strong will from individuals to be more than a number in companies’ active directory. They want their activities to be recognized as different from the ones of the neighbor. And who could tell them they’re wrong? ;-)
So the whole identity federation thing is about:
- segmenting the old active directory (where companies used to put users in bulk) to several user groups: say you give Marketing people access to Google Apps but not to Salesforce (that’d be a bad idea by the way!)
- providing users with benefits to seduce them (how about a single sign-on?) that will ease their corporate lives and encourage them to use it
- allowing a central control of Cloud apps so that companies don’t have to deal with all of them individually
Anything I forgot? :-)
PS: A big thank you to Brice Renaud for his time! And as a bonus, here’s his slide deck he used at Orange Business Live: