# Identity Federation ## Overview of the Identity Federation Federated identity management is an arrangement that can be made between two or more trust domains, to allow users of these trust domains to access applications and services using the same digital identity. An identity such as this is known as federated identity and the use of such a solution pattern is known as identity federation. Federated identity management is built upon the basis of trust between two or more domains. For example, a trust domain can be a partner organization, a business unit, a subsidiary, etc. ## Identity federation provides the following benefits 1. Users are required to remember only one set of credentials which provides a seamless user experience. 2. Single sign-on is supported in most implementations. 3. Avoids administrative overhead by delegating account and password management responsibilities to the resident identity provider, instead of having multiple identity silos to be managed. 4. Simplifies data management and storage costs. 5. Avoids privacy and compliance burdens. ## Use cases of federated identity management 1. Provide access to users from supplier, distributor, and partner networks. 2. Provide access to new users outside the traditional organization perimeter after mergers and acquisitions. 3. Provide access to users from commercial identity providers like banks, for example, Third Party Payment Providers (TPPs) in PSD2. 4. Provide access to citizens using national identity provider, for example, DigiD, Emirates ID, etc. 5. Provide access to users who own a public organization ID, for example, ORCID ID. 6. Social Login (sign-up/sign-in/connect), for example, Facebook, Google, LinkedIn, etc. 7. As a temporary arrangement for supporting transitioning between IAM systems. ## Identity federation with WSO2 Identity Server WSO2 Identity Server act as a proxy server to connect to the Service Providers to the external Identity Providers in different trusted domains. The important things is, there can be many IDPs which support different protocols and the service provider will communicate in another protocol. So here we need to have a protocol bridge to transform from protocol to another. The WSO2 Identity Server has that feature and it is very easy bridge any protocol to another over the authentication flow.

As in the above diagram here is the flow of the request 1. Service Provider initiate the authentication request to the Identity Server and there are many protocol's specific endpoints(inbounds) to handle the request based on the protocol which is used by the Service Provider. 2. This inbound endpoints pass the request to the authentication framework which is handle the authentication over Resident IDP or federated IDPs. 3. Then the authentication framework will redirect to the requested external trusted IDP to identify the user. 4. Once the authentication done in external IDP then it will redirect back to the Service Provider over the WSO2 Identity Server. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ws02.gitbook.io/project/iam-concepts/identity-federation.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.