Back to Basics 3 - SharePoint Security

SharePoint extends a strong security framework around its deployments to protect from unauthorized users, and errant code. SharePoint's role based security controls user access at different levels right from web app to list item. SharePoint solely depend on the authentication mechanism extended by external systems - Windows Auth or non-Windows Auth. The authorization process implemented within sharepoint assumes the user is properly authenticated.

The default authentication mechanism supported by SharePoint is "Windows Claims based auth" which is built on top of Windows Identity Foundation. In this model, user presents an identity to the Farm as a set of claims (eg: user name, email) and the external identity system is configured to give SharePoint all the 
info that it needs about the user with each request along with cryptographic assurance that the identity data come from a trusted source. SharePoint 2010 also support Windows classic authentication and ASP.Net forms based auth.

Access to all securable sharepoint objectts controlled thru a role based membership system by which users, groups are assigned rles to authorize their access to SharePoint objects. SharePoint follows a inheritance model in granting / revoking user access. A role definition will logically group a set of rights (read list item, create item etc.) that can be associated with a user , group as part of setting role assignment. SharePoint supports both Domain groups and SharePoint Groups. Domain groups will exist outside SharePoint with a less flexibility to manage (add users, remove etc) it but it can be used anywhere within the scope of the Active Directory Service. SharePoint groups are scoped to the site collection level and will be visible within the scope of that site collection. 

As part of code security , SharePoint supports app pool seperation, ability to keep code in GAC and BIN which provides different levels of acces, sandboxed solutions

Every web application runs in an IIS application pool that processes HTTP requests. The pool itself runs in a user account known as the application pool identity. In a multiserver farm, this is usually a domain user. The application pool identity is the user identity for code that runs in an IIS worker process. However, access to various SharePoint objects is determined by the permissions of the user who has made the request that is being processed. The isolation of web applications into separate application pools ensures that if one of them crashes, the others are not affected. The IIS worker process calls assemblies that may operate under their own additional restrictions. If the assembly is loaded out of the global assembly cache, it operates in full trust. However, if the assembly is loaded out of the web application's \bin directory, it is subject to the trust limitations that are defined by a CAS policy.If the request is for a sandboxed solution, the SharePoint execution manager that runs in the IIS worker process spawns a sandboxed worker process. The latter process runs within a highly restrictive CAS policy, is limited to a subset of the SharePoint server object model, and can only access resources within the site collection to which the solution was deployed.