Claims-Based Authentication
Claims based authentication is based on identity and trust. When a user signs in to SharePoint Foundation and SharePoint Server 2010, the user's token is validated and then used to sign in to SharePoint. The user's token is a security token issued by a claims provider. There are five supported sign-in or access modes in SharePoint Foundation and SharePoint Server 2010:
-
Windows Classic Mode Sign-In
-
Windows Claims Mode Sign-In
-
SAML Passive Sign-in Mode
-
ASP.NET Membership and Role Passive Sign-In
-
Anonymous Access
When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user's name, another might be an e-mail address. The idea here is that an external identity system is configured to give your application all the information that it needs about the user with each request, along with cryptographic assurance that the identity data received by your application comes from a trusted source. Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for the following:
-
Authenticating users
-
Storing user accounts and passwords
-
Calling to enterprise directories to look up user identity details
-
Integrating with identity systems from other platforms or companies
Code Access Security
With CAS we can specify our own code access security (CAS) policy for the web parts. It became easier in 2010. VS 2010 will automatically handle it while it builds it as a WSP. This is relevant when you deploy dlls in BIN folder of the application. In BIN deployment either you have to go for Full trust in web.confing Trust level else have to write CAS.
Cross-Site Scripting
Introduced to prevent Cross - Site Scripting (XSS) attacks. There is currently a Cross Site Scripting issue with SharePoint 3.0 and 2007 which could allow someone to maliciously run an arbitrary script that could allow elevation of privilege in the SharePoint site. There is currently no hotfix out for these issues however you can mitigate this issue by enabling the XSS Filter in Internet Explorer 8. Unfortunately this is not turned on by default for the Intranet Zone which is how the majority of SharePoint sites are accessed. In 2010 it is handled properly.
ASP.NET Membership User Token Converted to Claims Security Token
In SharePoint Foundation, an ASP.NET membership provider must implement the required System.Web.Security.Membership.ValidateUser method. Given a user name, the role provider system returns a list of roles to which the user belongs. The membership provider is responsible for validating the credential information by using the System.Web.Security.Membership.ValidateUser method. However, the actual user token is created by the SharePoint Foundation security token service (STS). The SharePoint Foundation STS creates the claims security token from the user name validated by the membership provider, and from the set of group memberships associated with the user name that are provided by the membership provider.