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.