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?
Share

Always Test Whether Your GUID’s Are Valid!

It is a best practice to not blindly use GUID’s, you should always test whether they are valid or not. This proves helpful in several SharePoint helper methods when you are doing custom SharePoint development, and is something that should be implemented in your corporate standard shared libraries.
Considering that testing for the GUID is a relatively simple process, it is worth taking the time to make sure that you implement a try/catch around it, and pass in the GUID as a string parameter. In order to set up the test of whether a GUID is valid or not, you are going to set up static flagging method (a Boolean) that will take a GUID string as a parameter.
[csharp]
public static bool isMyGuidValid(string guid)
[/csharp]
Then, you must setup a try/catch block that in the try block will intialize a new instnace of the System.Guid class and pass in the string GUID. If it returns true, great!, the GUID is valid!
[csharp]
try
{
new Guid(guid);
return true;
}
[/csharp]
When the catch block is executed, that means the GUID is not valid, so simply return false.
[csharp]
catch
{
return false;
}
[/csharp]
Yeah, it is a pretty simple convention, but you would be surprised how often untested GUID’s are used within WebParts and other SharePoint development pieces. It is a better code practice to test though, especially when the condition that you are building is so easy to construct!

Share