SharePoint Claims Based Authentication Architectures Explained Part 9 Specifying the Identity of a Given User

It is vital to be able to uniquely identity each user. This can prove to be very tricky at times because people don’t have that automatically as a part of them. A large portion of people are also very skeptical about anything that could affect their level of privacy. When you toss claims into the miss it can be something that takes time to determine how to do it right.

Keep in mind that not all applications out there really need to know specifically who a user is. All that is required is that something is used to keep the use of the application separated by user. You can even use a shopping cart to do this but even that is over the top for many applications out there today. For those that do have a per user requirement though that they track, you will definitely need to have some unique way of identifying every single user.

With traditional types of applications, there is a sign in name that is used to tell them from each other. When you have claims based applications in place though you will need to select what claims will be used to uniquely identify them. Then you will need to have the issuer set things up to give you the same values for them every single time that a user tries to access a given application.

It is a good idea to ask the issuer what claims they are set up to use for identifying users. When you use cross realm federation though you have to keep in mind that there is going to be more than one issuer involved. Each issuer does have it’s own URL that identifies it though. This can be used help with the process.

You will also find that all email addresses have some properties in them that are unique. This is why they are very good identifiers for claims. It is important that you realize you won’t have information about all of the users and claims out there for your application. When you go with cross realms you waiver that right of control in order to not have so much responsibility for your application.

Users are going to come and go using the token that they got from an issuer that you trust. With that token you will have information about who they are as well as what they have access to. Remember you don’t have to change your coding in order to support new users regardless of what realm they come from.

The issuer should be involved with the authorization decisions though. They shouldn’t be issuing tokens to any users that don’t have the credentials to access your application. Make sure everything is automated so that you don’t have to set up anything extra within your application. With a claims based application, you can give up lots of responsibility for the application. However, you do want to make sure you place that responsibility into the hands of a qualified issuer.


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.


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.