Identity Federation

Federating an individual’s or an entity’s identity in order to facilitate Single sign-on across intranet site or across multiple domains, achieved by setting up required trust relationships between the Identity provide and service provider.
Identity provider is an entity which stores the identity (authentication and authorization) information for the users. So every time user wants to access a services, instead of providing the authentication parameters (username password, certificates, tokens) directly to the service, its provided to the identity provider which host this information. On successful authentication, Idp provides an security token to the user which he can take it to the service. Service instead of authenticating the user, tries to validate the token and makes sure that it is issued by the authority which is trusted by the service. If token found legitimate, it grants the access to the user.
Lets look at a real life example of this federation scenario; lets say you go to a car rental company. Obviously car rental company will never ask you to prove yourself that you can drive the car, because it trusts DMV for doing that, so it asks you to go to DMV for verifying that you can drive. When you go to DMV, it tests your driving skill and if found eligible, issues an Driver’s License, which is nothing but your proof that you know driving and the rules of the road. When you go to a car rental company it will never ask you about your ability of driving but will just validate the Driving license.
          
In this example you would see that, Car Rental trusts DMV for verifying an individual’s ability to drive. This way both Car Rental Company and DMV does what they do best, one rents the car to the driver’s who need it and one verifies the individual’s ability to drive. More over, the License issued by the DMV has many more attribute and also used an an Identity Proof, so it is used to validate a user for multiple services.

See following Kapsule for more details