SharePoint Claims Based Authentication Architectures Explained Part 10 Issuing Claims

When you have several issuers the concept of where the claims should be issued is important. Take your time to find out about the different issuers and then use the one that is right for your needs. When you use the email as an identifier, that email address will remain the same regardless of the application being used. You want the claim to be issued close to the home realm.

This should be the first issuer in your chain, the one that is going to be the identity provider. With an action claim that is specific to a given application, you may want to go with a different claim provider to handle it depending on the specifications. You want to have an issuer that is close to the application though so that there can be authority in place. This will also help when you have policy changes that need to be secured.

In a traditional Role Based Access Control system, the user will be assigned to different groups. They are mapped onto roles and then onto actions. This is a good idea so that the actions for any given application can be accomplished by one that is familiar with it and that understands the actions of it.

Groups can be managed in a central store with the roles and actions decentralized. This allows them to be handled cy different departments. As a result the entire system is more flexible when it comes to identification and the authorization of data.

Issuers are placed at boundaries in the organization when there are several departments. Each one has its own issuer but there is a central issuer that is the gateway for claims to enter and exit through. There are four different issuers that could be called up depending on the circumstances:

  • Departmental issuer of the company authenticates the user, supplies email addresses, and handles group claims
  • Departmental issuer of the application maps roles onto actions
  • Central issuer of the company adds groups, roles are defined based upon those groups
  • Central issuer of the application maps roles from the user’s company to one that is understood by that company. Also an add role claims based on what is already in place.

As the request of each of the boundaries is found, there is a filtering system in place for the security. This makes sense when you are targeted with claims so that there are requirements in place and privacy policies adhered to.


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 8 Design Principles for Claims Based Applications

It can prove to be difficult to give guidance in the area of designed claims due to the fact that they work independently off of a given application. This next section is going to help answer questions you may have though and to offer a look at some different approaches you may want to consider implementing.

The Fundamentals of a Good Claim

There isn’t always a clear answer when it comes to the design for claims based applications. This is why it is important for you to understand the different variables and the tradeoffs that each one of them can offer you. With these examples though you should get a solid understanding of what types of elements need to be present in order for you to have a good claim.

The email address of the user is one thing to consider. When you have a candidate for a claim in a given system an email address is a good way to identify them. Just about everyone out there has an email for business purposes and it will be required for you to federate identity across realms. With an email name, you will be able to get your system personalized for each user.

There is some personalized data that can be used too. For example a user may have a specific skin or theme that they wish to use for a website. This is also a type of date that is specific for a given application. Choosing a skin or a theme here doesn’t make sense because it isn’t part of the users identity according to the verification process. Therefore this should be managed as a whole rather than individually.

There are users that will have permission to access date in your application. It can make sense to model permissions as claims but you nee to realize that soon you may end up with too many of them within your levels of authorization. A better way to handle such issues is to develop a boundary that will separate the authorization data from claims and that which you can handle another way.

A good example is that you have a cross realm federation that can be a benefit by allowing realms to be authorized for high level roles. The application will map these roles into fine detailed permissions with various tools. A common one used is Windows Authorization Manager. You do need an issuer that is designed to handle this fine detailed permission process though so that you can keep your claims at a higher level.

Here are a couple of questions that you need to ask before you go about attributing a claim:

  • Is the data going to be a core part of what I use for identity?
  • Will the date be used by only one application or several?
  • Will an issuer manage this data for me or should I have it handled directly through my own application?