A.1 Understanding a Simple Federation Scenario

Suppose Company A has a centralized user store that is used while authenticating to company’s most of the internal resources on its internal website.

In addition, Company A has a customer feedback application that employees and customers need to access. For this application, a second user store has been created. This user store contains accounts for both employees and customers. For this application, the centralized user store cannot be used because it contains only employees’ accounts.

In this situation, the employee must log in to both accounts to access the inner website and the customer feedback application. With federation, employees can access the resources of both sites by using a single login.

Figure A-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 A-1 Using Federated Identities

In this configuration, Site A is identity provider 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://nam.example.com/inner.

Site B is identity provider for the Bugzilla application. Both employees and customers authenticate to this site to access to the resources of the web server with the URL of https://nam.example.com/bugz. After an account has been federated, the user can log in to Site A and 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 does not 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.

Access Gateways in Figure A-1 are service providers and are configured to use Identity Servers as identity providers. The trusted relationship is automatically set up for you when you specify authentication settings for Access Gateway and select an Identity Server Cluster.

You can set up federation 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.