I’ve been speaking recently at a multitude of SharePoint Conferences.  It’s an honor to be asked to speak at these conferences and to be recognized as a SharePoint expert.  Because I attend so many of these conferences, I see a lot of the same speakers–typically speaking on the same topics that they are comfortable presenting.  Lately, however, I have noticed that the topics are slowly shifting toward integration:  SharePoint with Oracle; SharePoint with SAP; SharePoint with eDirectory.  All of these integration pieces are truly interesting and as I watch these presentations, I notice that one thing is seemlingly glossed over:  “Identity”.   This post is the first in a series of 3 posts that addresses Identity Management from a SharePoint perspective.  In these posts I will give some basic best practices in implementing them in an enterprise.

First, what is Identity Mangement?

So first, terminology.  When it comes to IdM in the SharePoint world, understanding what is what and who is who is key to undertanding.

• Entity – Each user (or entity) has an identity; that is, everything person, place or thing has something about it that identifies it.  It may be a username, a birthdate, an email address, or whatever.
• Repository (sometimes referred to as Identity Provider) – Where the relevant information about entities are stored.
• Claim – An assertion that an entity makes about itself.  For example, an entity may claim that its username is SlickRickIsTheMan@Live.com.
• Relying Party – The application, system, or user that requires validation from the Identity Provider that the Claim that has been presented is valid.
• Authorization – Permission to perform an action.
• Authentication – Proving an entity is indeed that entity.
• Federation - Validating another entity’s Identity Provider’s claim about entities for which it is the authoritative repository

For most SharePoint consultants, Identity Management (IdM) consists of mainly two things: Authentication and Authorization.  While IdM does encompass those two concepts (focusing on Identity), it is more than just AuthN and AuthZ.  The operative word being MANAGEMENT.  SharePoint is dependent upon an Identity Provider (IdP) to store its users.  Most SharePoint implementations use Active Directory to store these users. But what happens when the user has  a job change or has a name change or leaves the company or any of a plethora of other identity-affecting events?  SharePoint is unforgiving and unless the administrator loves manual maintenance these events can get tedious very quickly.  What is really needed is a Lifecycle Management plan for Identity.  Sure there are third party tools that address niche situations and some maybe two or three niches (and most are expensive), but they are just a cog in the big machine.

With the advent of SharePoint 2010 comes a new component called “Claims Authentication”.  SharePoint 2010 is Microsoft’s first enterprise application that is natively “Claims Aware”.  (I will go into Claims in a separate post).  This authentication makes an attempt to address the issue of identity which is really a complex issue.  For SharePoint to really put the final nail in the coffin of its competitors, it must address the issue of Identity and allow the consultants to seemlessly integrate it with *any* other enterprise system.  With the BCS (Business Connectivity Services) it comes close; really close.  But there are still concerns with exactly how SharePoint can address the Identity Lifecycle of its users.

In general, when looking at Identity Management solutions, it should be possible to do the following:

• View, create, modify, and delete users
• Change passwords
• Add or delete a user in a security group
• Approve or reject requests
• Delegate all permissions

Anyone who has dealt with SharePoint for any length of time knows that the above issues are either very difficult or taken care of by other systems (such as Active Direcotry).  But what if there are more than one password that belongs to a user that resides in another system?  Or even another username?  Things get complicated in a hurry.  Then I have to go to each system to make the appropriate changes (not to mention, make the decision as to which repository of information is authoritative).

Identity Management Hygiene

A good IdM solution (or system that employs good IdM) practices good IdM hygiene.  What does that mean?  For IdM to be reliable, it must be able to obtain an identity from an authoritative source.  Taking that a step further, it must also be able to ensure that the creation of that identity is monitored and audited. That alone probably declares many SharePoint IdM implementations unhygienic.  It should also go without saying that the identity should be locked down in such a fashion that only the true entity has claim on it and prevents any other entity from assuming it or altering it.

As was mentioned earlier, many (if not most) SharePoint consultants concentrate on two aspects of IdM; AuthN (authentication) and AuthZ (authorization).  There are at least two other aspects that should receive the same amount of focus.  These other aspects are Role Based Access Control (RBAC) and Monitoring.  In the next part, I will go into AuthN and AuthZ; delving into Claims Based Authentication and Federation, and then in Part 3 finish with RBAC and Monitoring.

————–

Follow Richard Taylor on Twitter @slckrck