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.

SharePoint Groups Context

Most of us (atleast me) forget a simple stuff around SharePoint groups often ...

SharePoint Groups are defined / exist at the Site Collection level. If we need different group members in a subsite then we need to create a new group for that subsite.

Sharepoint Groups are created in SharePoint Site Collection context.

So when the users are added into SharePoint Groups  will be reflected everywhere. so add specific subsite level groups after setting the Unique permissions.

For Eg: If you have 2 SharePoint groups (Admins, CommonUsers) at site collection level, when users added to these groups from anywhere (from top level site or sub siites) in the site collection will be reflected everywhere. You are advised to set unique permissions to subsite, then add sub site level groups  (SubSite1 Admins, SubSite1 CommonUsers) and add users to those groups.

Groups available in different site collections

Is it possible that I create a group that is available to assign permission to, under different site collections ?

You may not be able to create a group avaialable in multiple site collections.

The nearest possible option is - you can set User Policy on a web application which would allow you to set the following permission types in all its site collections.

•  Full Control - Has full control.
•  Full Read - Has full read-only access.
•  Deny Write - Has no write access.
•  Deny All - Has no access.

You can select individual AD users / AD security groups as part of setting up web app user policy from Central Admin...

Client side code to check user permissions

You can check for a specific user permission in client side code using the following snipppet

BasePermissions bp = new BasePermissions();
bp.Set(PermissionKind.AddListItems);
ClientResult<bool> manageWeb = context.Web.DoesUserHavePermissions(bp); context.ExecuteQuery();

The above code snippet checks whetehr the user has AddListItems or not