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 5 SharePoint Identity Across Realms

We have already talked about claims based identity and how to design a claims based application where the issuer is able to authenticate the users directly. You can actually take all of this one step further though. The process allows you to expand the capabilities of your issuer to accept a security token from another issuer. This means the user won’t have to directly authenticate it. Now the issuer is able to issue security tokens and to accept them from other issuers that it trusts.

As a result you will be able to have identity with other realms in spite of the fact that they are separate domains of security. This is a powerful ability that offers plenty of benefits. The process is accomplished by using the IT staff. They get to determine how issuers are going to be configured. You do need to understand these possibilities because they are the entry way to even more features for your application. You won’t have to change your application in any way though. Some of the different possibilities can offer some flexibility for your application design too.

Being able to maintain an identity database doesn’t have to be a difficult task. You can have a simple database that keeps the usernames and passwords that you need to manage in place. However, it is common for users to forget such information frequently. Chances are you have a high level of security in place for your business. Therefore it isn’t acceptable for you to just email those individuals new passwords.

It is very difficult to successfully manage a database for remote users. Lets say that you work for a partner company with a purchasing application. An IT staff make changes to your account as you work in the purchasing department. The IT staff gives you the role of purchaser so you are given permission to use the application. How are people with a different company going to learn about you being transferred to the sales department? What happens if you decide to quit your job for the company?

The changes will need to be found out, but don’t count on the human resources department to send out any type of notification. It should be something that the company you were employed with would need to manage. Storing information for remote users is often looked upon as a liability so keep that in mind. Any data that you store about remote users could turn out to be a liability for your business.

Over the course of time the data stored with a remote user will become old. There are some safe ways that you can expose applications so that a partner business will be able to use them. One of these methods involves decentralizing the process. You won’t have an issuer that authenticates remote users directly. Instead you will set up a trust relationship with an issuer that is part of another company.

Your issuer trusts their issuer to authenticate the users that are in the realm. These employees are satisfied because they don’t need any type of special credentials in order to be able to use your application. They will use the same single sign on ability that they used in their own company. Your application will work for them due to the came pass to get in. The claims you have to get the boarding pass for the remote users will be less powerful though because they aren’t really employees of your company.

It will be the responsibility of your issuer to determine those assignments. Your application won’t need to change either when new organizations are added as partners. This is a huge benefit of using claims because it allows your configuration of only one issuer to be accessed by so many new users out there.

It is possible to use claims to decentralize identity. This is going to eliminate data from becoming stale for remote users. Another benefit is that the claims will allow you to logically be able to store data about your users. The data can be stored with authority and be convenient to access and to use. Through the use of federation, many of the road blocks out there are removed so that new users can come in.

Your company will need to decide which realms to allow access to your claims based application. Your IT staff will be able to set up the relationships that need to be in place for them. They can get employees in a business that use Java to access your application but they won’t need to issue new passwords. They will only need to have a Java based issuer. Also, anyone with a Windows Live ID would be able to use your application.