Federated Identity management (FIM), sometimes called simply ‘federated identity’, is a buzz-phrase that has risen slowly but inexorably up the IT concept hierarchy in the last five years, and now sits among its most important and often-referenced terms. Its promise is huge, probably impossibly so, but still the lure draws ever more large organisations into its eye. But what are IT planners being offered with FIM, and can it be grasped in a tangible way to do useful work for companies?
The first thing to say about FIM is that it is not really a technology as such – despite what some vendors will appear to claim - more a concept for understanding how technologies such as web services can be used to make possible a goal that has started to obsess forward-thinking IT die-hards: how can users at different organisations share or ‘federate’ data and conduct transactions using each other’s networks?
It’s easy to describe such an ambition, less easy to overcome the immense technical hurdles that one encounters in trying to bring it to fruition. Even in its simplest format, that of tying two organisations together, it is complex, requiring common standards and tools to make headway. How will users be authenticated between networks and where will this common identity reside and be managed? Can basic enabling technologies such as single sign-on (SSO) be made available and if so, how will this be done? What are the security implications of such a project?
Now imagine that such a scheme is rolled out to multiple companies working together, and the complexity of what is being proposed starts to hit home. Companies struggle to implement some of these technologies for their own, sometimes disparate user populations, so extending this to third-parties using totally different technologies and suppliers is asking a lot.
But the point of FIM is that it lets companies collaborate and share information, and do so without creating complexity in the authentication of users and the ways in which they move around different data and applications provided on a network. FIM has the potential to streamline something that would otherwise be so cumbersome that it might prove almost impossible to manage without increasing workload or making security almost impossible to impose.
It’s best to think of FIM as expressing itself through one or more of a series of inter-related layers, which steadily become less abstract as you approach the sharp end of the people using it. The first and most general of these is the is known under the umbrella of ‘web services’, really just a convenient way to refer to a class of applications and APIs designed to be overlaid across the physical boundaries that would normally hem a user into working with data and applications only within a single department or company. FIM, then, can be thought of as a type of web service, though web services extend way beyond FIM of course.
Next come the technologies and standards that allow federated web services to exist, the most commonly discussed of which is single sign-on (SSO), itself a series of different technologies for letting users access network applications with a single act of authentication. Again, although SSO is not purely a FIM technology, it is key to making a federated system manageable because it automates a user logging into multiple resources.
Further down, the standards that enable SSO include things like security assertion markup language (SAML), a derivative of XML that is the work of the OASIS standards committee, through which identity information is exchanged between one network (or provider) and another to make SSO work smoothly.
SAML is important because as the protocol that underpins SSO, it describes what a particular user (or even computer) is allowed to have access to from, say, a web browser. SAML 2.0 has a number of features that make it especially useful for an enterprise considering federating resources.
First, it requires no ongoing synchronisation, and sets up connections on the basis of a particular request at a particular moment in time. This makes it simple and auditable. Second, it allows the communication of privacy settings and manages sessions better once the person has logged out of a federated resource. Perhaps most critically, it is an abstraction layer that can unite otherwise different authentication systems from different vendors, something that has thus far tended to cause a mountain of problems for FIM projects.
As with everything in IT, FIM has its share of technology politics, starting with two different camps looking to make their own agglomeration of standards its future. On one side, is the Microsoft-backed WS-Federation, which also includes IBM, CA, Red Hat, BEA and BMC, while on the other is the more established Liberty Alliance, backed by Sun, HP, and Oracle.
None of this should alarm companies looking into FIM. Ideas as big as FIM will be better served if there is competition between the industry’s leading players, regardless of which one wins out in the end, as one surely will. It is worth noting that some companies are members of both bodies.
Let’s not over-romanticise what FIM asks of companies, but a checklist of issues might start out with something along the following lines:
- FIM does not address the deeper questions of how companies authenticate their own users, and this is perhaps the first hurdle of any FIM project. In order to vouch for a user on someone else’s network, companies must have robust security management on their own systems. Companies collaborating with one another obviously have to have faith in each party to do this, because once implemented, federation gives a users access to resources on a separate company on the basis of their rights to do the same on their own systems - a big risk. Do you trust your partner? For that matter, do you trust your own security management?
- Following on from 1, what are the security implications of access? Federated employees are accessing multiple systems, which removes the layers of conventional security from these resources.
- Beyond this basic consideration, companies engaging in FIM need to be clear on its implications for compliance, or at least have some way of logging certain types of information and security exchange.
- If something goes wrong in a federated system, who carries the can for that failure? Federation can turn into deep inter-dependencies and not just informal exchanges, raising the stakes of failure into an uncomfortable red zone.
To succeed, FIM has to undo half a century of IT, based on the idea that IT is constructed around the logical arrangement and securing of systems into which users are placed. FIM, by contrast, has the potential to be radically user-centric, making users the centrepiece of an IT system, around which systems are built as digital supports. A systems mentality looks on users as existing on a hierarchy of privilege, with higher rungs gaining more authorisation and power, but within defined geographical and logical limits. A FIM way of looking at users is to see these systems from their point of view. That information, or the ability to transact, resides on the network of another company matters not if that it essential to the business objective. It should be accessible.
For the time-being, FIM will most likely be restricted to specific projects – getting two partners working together - with defined goals and timescales. Longer term, it has the potential to transform even the humblest IT operation into something quite new. But as a concept, federation surely represents the future of networks, so that they become not as islands of digital power, but overlapping ‘networks of networks’. It is happening already. But it will force companies to re-examine their own security processes before they jump into its whirlpool of potential difficulties.