How Lack of Identity Federation Leads to End-User Confusion and Increased Help Desk Calls

Let’s think where federation can be useful for today’s organizations. Consider the situation in which two companies, Company A and Company B, want to enter into some operational partnership. A trust relationship (typically created through a legal contract) is created so that the employees of Company A can access and update information on a Web site hosted by Company B. Maybe Company B is a supplier for Company A. Maybe they’re providing services as an outsourcer or external contractor. In this situation, the two companies are completely separate entities with their own Web security implementations and directories for the storage of their user identities.
Using federation, when employees of Company A attempt to access the Web site hosted by Company B they will automatically be provided access into it, just as if the application were locally hosted inside Company A. This process does not require another authentication or a separate username and password combination. Company B’s Web security system trusts that users who connect from Company A have already been authenticated at their home location. This trusted connection between the two companies works because both companies agree to support it. Federation is the systems and practices that are put in place to leverage and automate that trust.
With federation, a security relationship is created between the two organizations. This relationship typically relies on a common, standard language, such as the Security Assertion Markup Language, or SAML, to exchange authentication and authorization information between two organizations. The identity provider is the organization that conducts the authentication of the users that are to be federated. In our case, Company A is our identity provider. Users at Company A are all authenticated by Company A’s security system before being sent to Company B. The service provider is the organization who has resources to provide to the remotely authenticated users. Here, Company B is our service provider. Their Web site is available for use by users of Company A as well as perhaps many other organizations like Company A with which they do business.
Federation protocols such as SAML provide the necessary information to Company B’s Web site to enable Company A’s users to get appropriate application access. By clicking on a link in their own intranet, users at Company A are automatically redirected to Company B’s Web site. Along with that redirection is a set of SAML-specific XML-based information that securely informs Company B’s Web site that the incoming user has already been authenticated by a trusted partner.
As you can see through the above example presented graphically in Figure 1, federation provides a valuable service to the IT users of both companies. Company B gets pre-approval of users attempting to access their Web site, while the user’s of Company A get Web site access without requiring extra logins, username, and passwords for their users.
Without the right tools in place organizations who wish to share information and work more closely together can find themselves faced with a set of complex roadblocks. Lacking the ability to federate identities between these two companies, there are a limited number of options Company B can use to provide partner access to their Web site. For sites that require security to protect their applications, existing approaches generally fall short.
Traditionally what typically occurred in these partnering situations is for Company B to require direct login by all of Company A’s users. This requires Company B to create accounts for each Company A user that needs to access their Web site. Users will be required to login in order to use the site. Their activities and entitlements are tracked by their unique username. Data on the site can be properly secured against access by unapproved individuals.