SharePoint Claims Based Authentication Architectures Explained Part 6 Understanding Federated Identity In SharePoint

We have covered the ways in which federated identity works in a given realm. When you try to use it between your application and a local issuer in that realm you will get a message along the lines of Error! Reference source not found. That relationship will stay the same when your issuer works with one in another realm. The change that occurs is that your issuer is configured so that it can accept a security token issued by a partner company. It doesn’t have to come direct from authenticating users in your own company.

Your issuer will be trusting another issuer to authenticate users and then they don’t have to. This is the same way that your application trusts the issuer. Any user will start out by authenticating within their own realm. They will get tokens from the issuer that is accepting them instead of having to directly authenticate them. The issuer now has the ability to offer a token for the application to use. The token is then sent to the application. Most users don’t have a clue about this going on because the browser or smart client is doing it for them.

The application will only take tokens that have been signed by the issuer it trusts. This means remote users won’t get access if they are sending a token from the local issuer to your application. You may be asking yourself why would your business trust another company to authenticate the use of the application as it doesn’t seem safe?

Take a look at what is going on with this when you don’t have claims based identity in place. There are people from both companies that will hold meetings, come to terms, and then sign legal documents regarding those decisions. The IT staff of that other company will then be working with your own IT staff to take care of user accounts. The legalities of the contracts in place are there to make sure there is no abuse of the trust that is in place. This is a highly acceptable practice and it has been in use for years.

You may also be asking yourself why you need to create provisional accounts for remote users due to their information going stale in time? With claims based identity you will be able to automate the trust. This means you will be getting fresh information every single time that a user visits your application.

For example if an employee quits then the IT staff at her own company will quickly make it so her account isn’t active. They definitely don’t want to leave the door open for such employees to have access to their personal data once they no longer have a legitimate need for it. Once that process is complete, the employee won’t be able to authenticate their issuer or use outside applications.

No one is going to need to contact outside companies to tell them that someone is no longer working with them. The ability to decentralize that identifying factor in the system gives you all the information you need regarding remote users and who will have access to your applications. Now, there is a downside to federating identity to be aware of though.

Your issuer may become a point of failure for the relationships you have in place. You want your issuers to be very closely monitored. Sure, there is some risk involved when you add features, but the rewards of doing so often result in less overhead expenditures, high levels of security, applications that are user friendly, and users that are content with the process.