Today when duplicity problem has increased a lot, authentication has become a must. Authentication is the process of determining if someone is who they claim to be. It answers the question “Who is this guy really?” Taking advantage of SharePoint Server 2010 Claims Based Authentication feature may help you curb this duplicity issue. Even if you are a SharePoint Foundation 2010 user, you can enjoy the same feature to authenticate the user identity.
Most enterprise applications need some basic user security features. At a minimum, they need to authenticate their users, and many also need to authorize access to certain features so that only privileged users can get to them. Some apps must go further and audit what the user does. On Windows®, these features are built into the operating system and are usually quite easy to integrate into an application. By taking advantage of Windows integrated authentication, you don’t have to invent your own authentication protocol or manage a user database. By using access control lists (ACLs), impersonation, and features such as groups, you can implement authorization with very little code. Indeed, this advice applies no matter which OS you are using. It’s almost always a better idea to integrate closely with the security features in your OS rather than reinventing those features yourself.
In the real world, we face the following challenges:
* Privacy regulations and other pieces of legislation are impacting what kind of information we are allowed to capture and store about users, so in some cases we can’t just demand that people give us all of their personal details.
* Businesses want to inter-operate with other businesses, and government organizations want to provide more integrated services to citizens. However, different systems use different authentication systems and businesses want to integrate in a secure, legally compliant manner.
Consequently, claims based authentication in SharePoint Server is designed to address the two challenges mentioned above. Claims based authentication addresses privacy and other compliance concerns by requesting less specific, less personal information about people, and by trusting other parties or systems to do the “proof of identity” check. Claims based authentication addresses integration of different systems by allowing communications using open standards, and by providing a platform for developing more specialized ‘identity connectors’ between systems.
How to implement Claims based authentication?
The claims-based authentication is implemented in the following way:
* From a developer’s point of view, the platform that Microsoft is providing is called the Windows Identity Foundation. Earlier, it was called the Geneva framework. It provides a programming library suitable for building claims-aware applications. This library is also used by SharePoint 2010
* Active Directory Federation Services implement services to create, accept, and transform tokens that contain claims.
* Cardspace provides a user interface for users to select which “identity card” they wish to use for a particular system
Claims based authentication won’t address the lifecycle management of identity information.
Claims based authentication may let our system know that a user is a contractor from a partner company, but it alone won’t let us specify a rule that says “all of my company’s financial spreadsheets must not be seen by contractors”. Not only does claims based authentication not provide this capability, but neither do the role-based access controls provided by SharePoint. In fact SharePoint’s role-based access control model itself is too limited to address this. It still needs substantial improvements.
Claims based authentication feature was not available in MOSS 2007; SharePoint Server 2007 uses a native Active Directory-based authentication between machines and systems. In addition to claims based authentication, take advantage of other exclusive features in SharePoint Server 2010 and also enjoy some free SharePoint templates or web parts that come with SharePoint products.
