SharePoint Development & Administration + InfoPath

This article covers information relating to security for Application pages and page components in SharePoint:

• Selecting the correct base class to inherit from when developing Application Pages in SharePoint
• Securing Application pages with user permissions
• Specifying when the CheckRights method is called to determine if a user has access to the page.
• Programmatically check if the user has permission to access the page
• Code Access Security (CAS) Policy for SharePoint Components

A number of other useful resources relating to security of Application Pages and page components such as Web Parts are also referenced throughout this post, with a description of the main points covered in each to help you understand the requirements and implications of developing Application pages that need to be secured or unrestricted.

Choosing the correct class to inherit from when developing an Application Page

When developing an Application Page for Sharepoint, there are two base classes that can be inherited from which include a number of properties and methods that can be used to help control access to the page.  In some cases you may want a page to be accessible to any user, include anonymous users, but in most cases you will probably want to restrict the page and functionality to authenticated users with specific permissions on the site in which they access the page from.  The base page classes to help control this are the LayoutPageBase and UnsecuredLayoutPageBase.

LayoutPageBase Class
The LayoutPageBase class Includes various properties and methods to help control security for the page to restrict the page or content on the page to users.  This class should be inherited from in the code behind file ( .aspx.cs ) when creating a secured application page.  You can the override certain properties or methods to restrict the page based on permisisons.

To restrict based on specific built-in permisisons from the SPBasePermissions Enumeration, the RightsRequired property can be overridden.  The SPBasePermissions that a user requires to access the page should be returned by the property.  

In the example below, only a user who has access to manage lists and create subwebs on a site will be able to access the page.
protected override SPBasePermissions RightsRequired {  
}

To restrict a page to users with full access to the current site, the ManageWeb permission should be returned:
protected override SPBasePermissions RightsRequired {  
}

To restrict a page to only site collection administrators, the RequireSiteAdministrator property can be overridden to return true:
protected override bool RequireSiteAdministrator {
       get {
}

The RequireDefaultLayoutsRights property can be used to control when the CheckRights method is called to determine if the current user should be able to access the page:
Check if the user has rights when the page if first initialising - OnInit()
protected override RightsCheckModes RightsCheckMode {
       get {
}

Check if the user has rights when the page has finished loading - OnLoadComplete()
protected override RightsCheckModes RightsCheckMode {
       get {
}

UnsecuredLayoutPageBase Class
The UnsecuredLayoutsPageBase class should be used when developing Application pages that are unrestricted and accessible to all users including those who are anonymous such as a login page or the access denied page.

Validating a page request:

FormDigest can be used to pass security validation from a form page to teh page that processes the request to help prevent the form from being submitted from another page.  The following tag should be included in the form page:

<SharePoint:FormDigest runat="server"/>

On the page that processes the request, the ValidateFormDigest() method should be called to validate the request, especially in cases where you use RunWithElevatedPrivileges() to perform actions that the current user may not have explicit permission to do themselves.

protected override void OnLoad(EventArgs e) {
    SPUtility.ValidateFormDigest();
    //page logic
}

Programmatic Validation of User Permissions:

Base Permissions in SharePoint - Checks if the current user has specific permissions on the current web using the SPBasePermissions Enumeration.   The example below requires that the current user has permission to manage lists (SPBasePermissions.ManageLists) on the current site to be able to access the application page.  View the Complete list of SPBasePermissions (MSDN).

protected override void OnLoad(EventArgs e) {


        //Use has the required permissions, execute page logic here
        //Current user does not have the permissions required to access the page
    }
}

For a more detailed example, please see the Validating User Permissions section of the MSDN article for Securing application pages in SharePoint.  Other examples of restricting an Application Page with permissions included in the article are:

• Restricting a page based on “Role Definitions”, which are the permission levels associated with a site or site collection.  Basing application page security on Role Definitions may not work in all cases as it is possible to alter the names of permission levels on a site.
• Restricting a page to members of a specific group.  Using this method also has limitations as the names of groups in SharePoint may change.

Related External Resources

SPBase Permissions Enumeration
The SPBasePermissions Enumeration provides a range of built-in permissions that can be used to manage security on pages and content in SharePoint.  Many components that are part of teh SharePoint object model use the SPBasePermissions class to restrict features at different levels such as a Site / Web, Page (eg. Application Page) or content.  The SPBasePermisisons enum is also used by some controls that can be incorporated into a Master Page, Application Page or .aspx page in SharePoint using SPSecurityTrimmedControl.  

Securing Application Pages in SharePoint
MSDN Article: Securing Application Pages in Windows SharePoint Services 3.0
This article (also referenced earlier) covers what is required to secure an Application Page in WSS 3.0, but is also applicable to MOSS 2007 and SharePoint 2010.  It is highly recommended that you read and become familiar with the contents of this article when developing Application Pages in SharePoint.  It first explains some benefits and reasons for using Application Pages, then provides information and example code on how to secure Application Pages.  Details include Validate page requests using FormDigest which ensures that the ValidateFormDigest method is called to validate the page requests and user, Validating User Permissions to restrict the Application page to only users with certain permission levels using SPBasePermissions (built-in permissions), Role Definitions (customisable permission levels applied to sites and content in SharePoint) and Group Memberships (groups that a user is a member of).

Article: How to secure Application Pages
This article covers the basics of implementing security for Application Pages, which takes from some of the main points described on the MSDN article above: Validating Page Requests using FormDigest, Validating User Permissions with SPBasePermissions and Hiding Application Pages.

Security in SharePoint application pages: Choose the right base class for your pages
This post explains an important implication of developing an application page without taking caution as to the class that the page is derived from.  It notes that when creating a new WebForm, the default class that is inherited is the System.Web.UI, which can result in even anonymous users having access to the page and functionality.  The UnsecuredLayoutsPageBase or LayoutsPageBase classes should be used to help control who has access to the page.

Code Access Security (CAS) Policy
Code access security comes into play when a custom solution in SharePoint has code that needs to be executed.  There are a number of ways to manage solutions with custom code, including installing an assembly in the GAC and altering the trust level of the SharePoint web application in Web.Config to the “Full” trust level.  The articles below provide some insite into different methods to manage CAS and when they are appropriate in different scenarios to help ensure that your SharePoint environment remains secure.

Microsoft Windows SharePoint Services and Code Access Security
This detailed article talks about implementing Code Access Security policies for SharePoint as well as customising the default security settings to suit different needs.

Creating a Custom CAS Policy File For SharePoint
This article explains how to create and implement a custom CAS Policy file in a SharePoint environment.

Code Access Security policy template for Visual Studio 2010 SharePoint Developer Tools
Implementing CAS Policy Files into SharePoint solutions created using Visual Studio 2010.

Deploying a Web Part with Code Access Security in Visual Studio 2010 (SP2010)
Implementing a CAS Policy in custom Web Part solutions using Visual Studio.