Handling these trusts, I suppose, is the most challenging task of Federation, ranking before the correct choice of the standards or the multiple hurdles you have to get over as an administrator of the different products. To me, it seems to be even more challenging than explaining the usefulness of Federation to the responsible people in business.
Only now, the topic is moving into the focus, which is due to the fact that in the beginning, the application area of Federation was rather limited. In a relation between just two enterprises or between one of the big telecommunication providers and a limited number of service providers, the problem can be handled, and the same is true for the first attempts of using Federation within one enterprise.
Too many trusts
In contrast, looking for example at more intricate implementations of Federation within a branch of business, we realize the whole extent of the problem. As an example, let me cite a scenario with ten major producers und 500 suppliers of an industry – these figures of course being very small compared to the likes of automobile industry or chemical industry – and further assume that each of the producers creates a Federation relation with only half of the suppliers, and vice versa. In this case, for every supplier there are five producers, which is manageable, but for each producer there are 250 suppliers. This situation, at the latest, poses a serious problem, because every single producer must define and maintain 250 trusts ¬– multiplied by ten producers we are getting to an amount of 2.500 trusts.
The reality is even worse – not only with Identity Management along the supply chain. Considering the number of services in SOA-based application infrastructures, here, too, one is faced with having to configure a huge number of trusts.
Additionally to the manual management of Federation relations, various ideas been developed meanwhile to tackle this problem. One of the possibilities, which was strongly recommended by Dick Hardt on the European Identity Conference, could be the utilization of user-centric Identity Management approaches. In the main, this model turns against the idea of “circles of trust” as, for instance, propagated by Liberty Alliance. Instead of realizing a highly complex interlocking of trusts, each service provider trusts one Identity Provider (or the user himself, for example by use of a “self issued infocard”).
The second possible way of addressing the problem is a trust broker as offered by Covisint for selected fields of application. In this case, the enterprise is in charge with the central management of the identities, and each one of the suppliers and producers would have to define just one position of trust.
The third solution from Symlabs is the Federated Identity Access Manager with a special gateway module which bundles trusts, thereby assuming on a technical level the role which Covisint claims for itself as a service provider.
Of course, all approaches have their strengths and weaknesses. The user-centric management stands and falls with the accepted Identity Providers and with the information users make available about themselves, for example on Infocards. The service provider model calls for such a trustworthy provider. A solution which is part of a Federation product, however, only goes well for the Trust Management of an enterprise, as for example for the security issues for SOA´s, but not between enterprises.
The variety of the approaches reveals the drive of the Federation market. With practical problems growing, new ideas are being developed. In the opinion of Kuppinger Coe + Partner, all of the approaches have merits, especially in that they are not mutually exclusive, but address different aspects of Trust Management. We recommend to evaluate these solutions when developing Federation concepts.