Suppose Company A has a centralized user store that does the authentication for most of the company’s internal resources on its inner Web site. But Company A also has a customer feedback application that employees and customers need access to, and for this application, a second user store has been created. This user store contains both employee and customer user accounts. The centralized user store can’t be used, because it can contain only employee accounts. This means that the employee must log in to both accounts to access both the inner Web site and the customer feedback application. With federation, the employee can access the resources of both sites by using a single login.
Figure 6-1 illustrates such a network configuration where the user accounts of Site A are configured to federate with the user accounts at Site B.
Figure 6-1 Using Federated Identities
In this configuration, Site A is the Identity Server for the corporate resources, and the employees authenticate to this site and have access to the resources on the Web server with the URL of https://provo.novell.com/inner. Site B is the Identity Server for the Bugzilla application, and both employees and customers authenticate to this site to have access to the resources of the Web server with the URL of https://provo.novell.com/bugz. After an account has been federated, the user can log in to Site A and have access to the resources on the Web servers of both Site A and Site B.
In this scenario, Site B is not as secure a site as Site A, so federation is configured to go only one way, from Site A to Site B. This means that users who log in to Site A have access to the resources at Site A and B, but users who log in to Site B have access only to the resources at Site B. Federation can be configured to go both ways, so that it doesn’t matter whether the user logs into Site A or Site B. When federation is configured to be bidirectional, both sites need to be equally secure.
The Access Gateways in Figure 6-1 are service providers and are configured to use the Identity Servers as identity providers. The trusted relationship is automatically set up for you when you specify authentication settings for the Access Gateway and select an Identity Server Cluster.
Federation can be set up between providers in the same company or between providers of separate companies. For example, most companies have contracts with other companies for their user’s health benefits and retirement accounts. Their users have accounts with these companies.These accounts can be federated with the user’s employee account when both companies agree to set up the trusted relationship.