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.


SharePoint Claims Based Authentication Architectures Explained Part 3 SharePoint As A Browser Based Application

WIF, short for Microsoft Windows Identity Foundation, is a set of .net frameworks that allow for the creation of claimed aware applications. It gives the user the logic that is needed in order to successfully complete any WS-Federation requests. This is the protocol that builds onto others to offer the trust and security. That is why you are allowed to request a security token when you are using an application that is browser based.

With such a scenario, it appears that the claims in WIF are similar to authentication. When a user is going to sign in, the WIF redirects them to the logon page. Once the user has been authenticated then they will be taken back to the application automatically. You may see a page called Login.aspx but that could be nothing more than an empty page. This is there for those users that need to use a smart card for authentication.

All issuers will be configured to use a method that is natural and that is secure for them to sign in. A simple username and password is usually good enough. However, there are ways for Windows to cover the needs of employers that want a more secure method to be in place. Here are some examples to make that process easily understood.

wa = wsingin 1.0 wa is for action and it will tell you if you are logging in with the wisignin1.0 or if you are logging off with wsingout1.0.

wtreatlm = – wtreatlm is for target realm. There is a Uniform Resource Indicator that is able to identify this application. The URI is used to identify the application that the user has logged into. It also allows other tasks to be done that are associated with the claims for the application as well as replying to addresses.

Once the issuer has authenticated who the user is, it gathers those claims that are necessary for the application with the wtrealm identifying what the target application is. All of this is offered with the security token and there is a privacy key. The application can encrypt the tokens too and then the public key ahs to be used to authenticate them.

The issuer will be told which application they are using so that the claims issued will only be for that particular application to operate. The issuer will ask the browser to take them back to the application. This will send the token to that application for the claims to be processed. After this is done, the user will have access to that given application.

Some of this process may sound familiar to you. This is due to the fact that the forms authentication uses a very similar technique inside of the return URL parameter. This is done when the issuer returns to the HTML page of the browser. This creates the

with the encoded tokens inside of it.

The action of the form is going to submit the toke to the URL that is configured for that application. The user won’t see this form because the issuer has JavaScript in place to post it. Should those scripts be disabled though the user will have to click a button in order to be able to post the response to the server.

For the user there is a Windows authentication in place. The user will click on the link in the application and then the browser will be redirected in a matter of seconds right back to the application. The user will login at that point. Should the issuer require more information from the user such as a username and password or the use of a smartcard it will be done at that time. From the users point of view this type of logon process is always the same no matter what they are accessing and that is what they are after.


SharePoint Claims Based Authentication Architectures Explained – Part 1 – Intro To Claims Architectures

You will find that the internet offers plenty applications that are interactive. This allows users to be able to access them simply by reading a hyperlink in text and then clicking on it. When this process is initiated, the information they seek more about will come up. The reader anticipates that the websites are going to monitor who is logged into them and for how long. No one wants to have to put in their password over and over again to be able to benefit from such a process though.

Instead they want to be able to enter it once and then to access any of those company based applications from it. It is very important for any such development that is created for the web to be able to support this need from the user’s point of view. It will be referred to here as a process called single sign on. You may hear it referred to out there though as passive federation.

Many people have had experienced with the world of Windows, and that is a single sign on concept that they use. Once you have logged in with your password the first time that day you will have access to all of the resources that are part of that hosted network. Windows is able to authenticate that password for each entity you wish to access. This is why you can avoid having to type it in again and again.

Kerberos is extremely popular but that has also resulted in it losing flexibility as a cross source. The domain controller is the one that has the keys to all of the resources that people within a given organization are able to access. There are firewalls in place that carefully guard such activities. When you aren’t at the office, you can access them through a VPN to the corporate network connection.

Kerbos isn’t very flexible when it comes to the information that is provided either. Many people would love to see it include arbitrary claims including email address access. However, that isn’t something that you are able to find at this point in time. With claims though you have such flexibility present. You are only limited in what you can access by two things your own imagination and the policies that your IT developers for the business have in place.

There are standard entities in place that allow you to cross different boundaries in terms of security. This includes both platforms and firewalls. They reason for this is that it makes it easier for it all to be able to communicate with the others. With this in mind, the application doesn’t have to verify the users.

Instead, the application needs to have a security token that is provided by the issuer trustee. When the IT department needs to increase security then the users have to use a smart card rather than a username and password for access. However, it won’t have to be reconfigured so that isn’t a time consuming process.

Even so, domain controllers will still be in place to offer security when it comes to the various resources of a given organization. There will be various issues for businesses to consider too. For example they will need to figure out how to resolve issues relating to trust. There are legal issues that have to be reviewed before entering into a contract with one is completed. You can be confident that claims based identity won’t change those needs that are already in place relating to such issues.

What will change though based on it is that there will be layers to the claims. Some of the barriers that are now in place will be removed. The result will be a single sign on solution that is also flexible for the needs of the users. Claims work is designed to be able to work within the security that already exists. It will eliminate many of the technical problems that are currently experienced.