When building an Internet-facing website on the SharePoint 2010 platform, the last thing you want is to have your visitors browse your system pages. To prevent this from happening, SharePoint 2010 has the ViewFormPagesLockdown Feature. But what if your visitors are authenticated?

SharePoint 2010 For Internet Sites

SharePoint 2010 is a rich platform for building Internet-facing websites. Using its capabilities, you can create mini-sites for supporting marketing campaigns as well as large company portals for enterprises. No matter the purpose of the website, the Microsoft SharePoint 2010 platform can help you reach your audience.

More value through personalized experience

In the last few years you can notice a particular shift on the web more clearly. While in the beginning many websites were only sending content, nowadays more and more organizations look for interaction with their audience. Delivering personalized experience to the visitors can help in increasing the website’s value.

Content Management in SharePoint 2010

SharePoint 2010 uses in-place editing, meaning that both content editors and visitors look at one and the same website. To get the most of the website and to allow managing content, SharePoint 2010 offers content editors a number of pages often referred to as system pages. As you can imagine, those pages are for content editors’ eyes only and should not be accessible for the website’s visitors.

Visitors vs. system pages

To prevent anonymous visitors from browsing system pages on a public-facing website, SharePoint 2010 offers the ViewFormPagesLockdown Feature. It is a hidden Feature, which is a part of the standard Publishing Site, which, upon activation, prevents anonymous visitors from accessing system pages. Whenever an anonymous user browses to a system page, he will be prompted to authenticate.

As I mentioned before, more and more websites offer nowadays personalized experience and for this they ask users to login. While this allows content authors to tailor the content to the profile of particular user, it introduces a flaw. Because the visitor is not anonymous anymore, he is allowed to browse system pages!

There is however a way to extend the idea of the ViewFormPagesLockdown Feature beyond anonymous users and prevent authenticated visitors from accessing system pages.

Preventing authenticated visitors from accessing system pages

With introduction of claims-based authentication, SharePoint 2010 changed the way the visitors can login to a website. Using claims it is now easier to determine which authentication mechanism the visitor has used or if he is a content author and should have access to system pages or not.

To illustrate how to prevent authenticated visitors from browsing to system pages I created a standard SharePoint 2010 Publishing Site and enabled forms-based authentication on it. To support new visitors the content of the site is also available to anonymous users.

Because the standard Publishing Site has the ViewFormPagesLockdown Feature enabled by default, anonymous visitors are not allowed to browse system pages.

When signing in, the user can select if he is a content author and want to log in using his Windows account or that he is a visitor and has a Forms accounts to log in with. Although the way you allow your visitors to sign in to your website may vary depending on your requirements, SharePoint 2010 allows you to configure multiple authentication mechanisms on the same website and URL which makes it easier for different users to exchange links to content on your website.

After login in as a visitor using a forms account, we can still visit the site – just as previously. The difference is however, that since we are authenticated now, SharePoint 2010 allows us to browse system pages as well.

The easiest way to prevent authenticated visitors from browsing system pages is to apply a User Policy to a Web Application. Using claims can simplify the process, especially if you allow your visitors to login using multiple authentication mechanisms. In this simple scenario we will use the information about the used authentication mechanism to determine if the user is allowed to access system pages or not.

The first thing that we have to do, is to create a Permission Policy that will prevent users from accessing system pages. For this, go to Central Administration and from the Application Management group choose the Manage web applications option.

Next, select your web application and in the Ribbon, from the Policy group, click the Permission Policy button.

In the Manage Permission Policy Levels dialog window, click the Add Permission Policy Level button.

Next, in the Add Permission Policy Level dialog window, type as Name Deny System Pages and in the Permissions section select the Deny checkbox for the View Application Pages permission.

Confirm your changes by clicking the Save button and close the Manage Permissions Policy Levels dialog window by clicking the OK button.

The next step is to associate users with the Deny System Pages policy. Ensure your web application is still selected and in the Ribbon, from the Policy group click the User Policy button.

In the Policy for Web Application dialog window click the Add Users button.

In the Zones drop-down list, select the Zone to which your policy should apply and confirm your choice by clicking the Next > button.

Next, in the Users field, select which users should be disallowed from browsing system pages. Although the field is called Users, you can use claims as well what simplifies managing permissions for visitors using different authentication mechanisms. In this scenario I have used the AspNetMembership claim which represents all users authenticated using forms account. In the Choose Permissions section, select the Deny System Pages Permission Policy we have created previously and confirm your changes by clicking the Finish button.

With that we have secured our website by preventing authenticated users from browsing system pages. If you navigate to your website now, authenticate using a forms account – just as you would as a regular visitor, and try to access a system page, you will see the access denied page.

Bonus: Automating configuration of User Policies

If you’re using structured and repeatable deployment, you might be interested in how to automate the process of creating a Permission Policy for your Web Application and associating it with authenticated visitors. The following PowerShell script shows how you can automate the process described above.

param (
    $WebApplicationUrl
)

$wa = Get-SPWebApplication $WebApplicationUrl
$wa.PolicyRoles.Add("Deny System Pages", "", "EmptyMask", "ViewFormPages")
$wa.Update()

$claimType = "http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider"
$claimValue = "AspNetMembership"
$claim = New-Object Microsoft.SharePoint.Administration.Claims.SPClaim($claimType, $claimValue, "http://www.w3.org/2001/XMLSchema#string", [Microsoft.SharePoint.Administration.Claims.SPOriginalIssuers]::GetIssuerType("SecurityTokenService"))
$encodedClaim = $claim.ToEncodedString()

$policies = $wa.ZonePolicies("Default")
$policy = $policies.Add($encodedClaim , "Authenticated visitors")
$policy.PolicyRoleBindings.Add($wa.PolicyRoles["ViewFormPagesLockDown"])
$wa.Update()

Summary

SharePoint 2010 is a flexible platform for building Internet-facing websites. Because it uses in-place editing both visitors and content editors use the same website. To prevent anonymous visitors from accessing system pages, SharePoint 2010 provides the ViewFormPagesLockdown Feature which allows you to prevent your visitors from browsing to system pages. Although the ViewFormPagesLockdown Feature doesn’t work with authenticated visitors, you can easily secure system pages from being browsed by authenticated visitors by creating a Permission Policy and associating it with authenticated visitors.