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.


Get SPGroup, If Not Available, Create!

When developing for calls to SPGroup objects in SharePoint, often times it is best to guarantee that the group exists by placing a creation guard clause in that will create the SPGroup if it is not available off the SPWeb from the initial query.

The GetGroupOrCreate method provided below does just that:

public static SPGroup GetGroupOrCreate(SPWeb web, string name, string description, SPUser owner, SPUser defaultUser, bool associate)
SPGroup groupToReturn = null;
foreach (SPGroup group in web.SiteGroups)
if (!group.Name.Equals(name, StringComparison.InvariantCultureIgnoreCase)) continue;

groupToReturn = group;

if (groupToReturn == null)
web.SiteGroups.Add(name, owner, defaultUser, description);
groupToReturn = web.SiteGroups[name];
if (associate && !web.AssociatedGroups.Contains(groupToReturn))
return groupToReturn;
} [/csharp]

The SPWeb parameter is the web associated with the SPGroup you wish to query or create

The name parameter represents the name of the group to query or create

The description parameter provides a description for the SPGroup if creation is required

The owner parameter is the owner of the SPGroup represented by an SPUser object

The defaultUser parameter is the first SPUser to be put into the SPGroup

The boolean associated defines whether the SPGroup should be added to the SPWeb.AssociatedGroups collection

It is important to note that I am using InvariantCultureIgnoreCase to perform a case-insensitive string comparison using the word comparison rules of the invariant culture.


Removing Duplicate SPList Objects From Typed Collections

One of my friends had a slight dilemma in his code this morning where he had a recursive loop, subject and constrained by some limit logic, which iterated through SPList objects in an arbitrary SPWeb and returned a large typed collection of SPList objects. The collection was afterward used for massaging out some specific SPField values, assimilated later by a detached business application.

One difficulty that he was running into was the occurrence of duplicates that were taking place during the generation of the collection. He was questioning if it was workable to inspect and eliminate duplicate SPList objects that occur before returning the final SPList collection.

In order to do this, we of course necessitate a unique identifier for each object, so it makes sense to use the SharePoint generated SPList.ID property which guarantees a unique value. Within the method, we are creating two other collections, a temporary typed dictionary object which will hold the ID values to later act as a guard clause, as well as a provisional SPList collection which will provide return allocation.

public static List CheckAndRemoveDuplicateSPList(IEnumerable inputList)
Dictionary tempDictonary = new Dictionary();
List tempListCollection = new List();
foreach (SPList list in inputList)
if (!tempDictonary.ContainsKey(list.ID))
tempDictonary.Add(list.ID, 0);
return tempListCollection;

That should do the trick!