SharePoint Claims Based Authentication Architectures Explained Part 7 Transforming Identity In SharePoint

The role of the issuer involves taking the incoming identity and making it into a secure token that can be used for a given application. The token is very similar to a boarding pass it has pertinent information about the identity of the user. The only information that is on it is what the application needs. This is why such boarding passes often have a role that can be used immediately. This is faster that relying on Windows groups.

The issuer is often thought of as an identity transformer. It is able to convert the incoming identity into something that is readable to the application. There are users that can have one sign on credential that allows them to access all of the different application they may need. This is because there is an issuer in the realm with the trust to authenticate all of them.

There is a local issuer that offers claims to applications in their own realm as well as to those that are in others and need access to multiple applications. It allows them to use their local applications and those that are remote all with just that one credential being in place rather than needing one for each of them.

The Active Directory Federation Services (ADFS) relies on a rules engine that will support the claims transformation. They have a set of rule in place that say when a claim of X type is make with X as the value then issue this type of claim. For example you may have an application called Managers that allows special access to certain features. This claim will take that user to a Mangers group in the realm. That is where they will always be sent.

A partner group may have a group called Supervisors that needs to gain access to that Mangers area in the application. Through the transformation process both the Supervisors and the Mangers can access it as long as the issuer has trust for this to be acceptable. This is all possible due to the way in which the rules are written in the ADFS. The issuer has to be designed to support these types of transformations because the terminology used in each company can be very different.

Hopefully you now see what is possible with the concept of cross realm federation. Here are the steps involved with a browser based application:

  • A user in a remote realm clicks a link that will take them to your application
  • That user is redirected to your local issuer
  • The issuer redirects the users browser to the issuer that is in their realm.
  • The local issuer authenticates a token, sending the user’s browser back to your issuer with the token
  • Your issuer will validate the token, transform the claims, and then issue a token for your application to be used
  • Your issuer sends the user’s browser back to the application with a token that has the claims your application needs on it

In step three you may be wondering how the issuer knows that the user is from a remote realm. Why doesn’t it think that she is a local user and thus attempt to authenticate her directly first? Of course by doing so the user wouldn’t get in and they will be upset about it. Also, how does the issuer know that the user is from one particular realm versus another?

You will have more than one partner and so all of them will be differentiated out there. The home realm discovery is where the issuer has to determine if the user is from the local realm or one of the partners. If that user is local then they can be authenticated directly. If they are remote then the issuer has to be able to find out what the URL is to redirect her to so that they can be authenticated by the home realm issuer.

There are a couple of different ways in which this situation can be handled. The first one is for the user to help in some way. When the browser of the user is redirected to the ADFS, it will stop the protocol and display a web page to the user. Here they will be asked what company they are employed by. The credentials in place are only good for one company per user so they can’t give you false information here and continue to with any hopes of gaining access.

Once the user clicks the link for the company they are with, the protocol will continue the process. The issuer will know what to do from there. You can also set it up so that the user is only asked which company they work for one time. After that there can be a cookie in the browser that will always display that information without it being asked for in the future.

There is another way to handle this and it involves adding some type of hint to the query string in the link that the user clicks on in the first step. This query string is called whr with the hr being representative of home realm. It is a good idea for the IT department to ensure all of the links to remote applications include this information. That way the application is more user friendly. At the same time it will protect the privacy of the company as it doesn’t require revealing who all of the partners happen to be.

The issuer is going to find this hint and then map to the right URL for the home realm of the user. This means they won’t need to ask the user who their issuer is because the application is going to use the information it has available. A cookie will be in place to make sure users don’t have to take time to answer such questions.

The best way to get the users help for web applications is through the use of a web page. They are going to be interactive and the browser will conveniently be able to display a home realm discovery page when necessary. You may be wondering how to take care of this when it comes to web services and even your rich clients? Information cards can be a very useful tool for such circumstances.


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.