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.
More Here
Courtesy:http://blogs.perficient.com/portals/2010/11/03/sharepoint-and-identity-management-part-1-of-3/