Company A has acquired Company B. Now company A & Company B users have to be authenticated using federation. For example, think that Company A is Microsoft and Company B is Skype. Both Microsoft(LiveMessenger) and Skype has users registered for IM. Now Microsoft has to provide a unified experience to all the customers. How can we solve this problem using federation? There can be:
1) Skype only users 2) Live only users 3) Live and Skype users
At the end, the customer should only log in once and they can log in to Skype or Live messengers. We should not ask the login again.
Now, Live Service and Skype Service are Relying parties. Skype and Live expects application specific tokens for REST based communication.
As a developer at Microsoft, I understand I need to create an IdM. Do I need to migrate all existing users from Live and Skype to the IdM? Or should the IdM call the user management service of Live and Skype in the background?
I understand we need to exchange SAML token for an application specific token, how exactly it should be done? Do I need to expose a service endpoint for that at Skype and Live services?
There are two sides to this problem:
Identity and Entitlement management
The first one is called Identity and Entitlement management and it deals with modeling of which users exist, how can they be authenticated and what can they access. There are two ways to approach your situation:
In the first approach you would like to end up with a single corporate-wide identity for your users (think of a single Google account giving access to all sorts of Google services). This by far provides the best user experience, but requires migration of users, new registration processes, ...
You would introduce a new centralized authentication service (an Identity Provider, IDP), where each user has an account which enables her to access services of Company A (which the user has entitlement to access) using single sign-on.
You would then migrate existing users from Skype to the IDP (i.e. the current Skype accounts would now directly allow you to authenticate at IDP). And you would enable a registration process which allows user to establish a new account at IDP by first authenticating with their (now legacy) Live credentials. You could of course choose a different "default" account, try to merge both of them together, or require each user to register anew.
In the other approach you only want to enable single sign-on (= users will be able to access applications with a single authentication), but want to keep the accounts and registration processes intact.
Again, you will want to create an Identity Provider, but this time you will allow users to select whether to authenticate using their existing Skype or Live account. After selection, you verify the credentials with the selected service (e.g. using application's APIs, or any other available way). Users still register like they used to directly in the Skype/Live services.
Identity federation
The other side of this problem is called Identity federation and in its core it deals with the problem of connecting your applications (relaying parties or service providers - different terms for the same concept) to the IDP service; in other words externalizing authentication.
And here starts the discussion about different federation protocols, such as SAML, SAML 2.0, OpenID, (partly) OAuth 2.0, WS-Federation, custom protocols, ... which are all slightly different ways to do the same thing - securely transfer information about the fact that user authenticated between two systems.
You should select one of these protocols and enable your applications to support it (either by directly modifying the applications, or using a proxy which routes all access to the application and is able to support the selected protocol - e.g. an IIS or Apache plugin). This typically exposes a set of endpoints at your application which are able to accept messages sent from the IDP (e.g. SAML messages).