Lockdown WSS system pages on public SharePoint sites
Using WSS on public sites means giving anonymous access to virtually all the pages in your site, including all the different list views and document libraries. People won’t be able to do anything they are not allowed to because of security trimming, but they will be able to get to see the standard SharePoint UI. There maybe also implementation details you may not want them to have access to or ‘public’ content which isn’t ‘always’ public.
MOSS Lockdown Feature
MOSS has a feature which provides this functionality, the ViewFormPagesLockDown feature. For me there are three problems with this…
1. It only works with MOSS and I want it to work with WSS.
2. It does not cover everything I want locked down.
3. I don’t have any control over it, maybe I want some things still available.
More about this feature is available from…
Securing MOSS 2007 Publishing Sites with Lockdown Mode
Anonymous Users, Forms Pages, and the Lockdown Feature
Master pages
Having completed the SPWorks website using WSS I wanted to restrict access to any of the standard SharePoint pages, whilst still allowing access to the custom webpart pages. It would be easy enough to add a control to the default.master page, but this will un-ghost it and would have to be done for every default.master on each site. The other problem is that this would not work with pages in the ‘Layouts’ folder which use the application.master page. You can’t really change this, without affecting all site collections in the farm.
Realistically I wanted a solution which would work with any of the default SharePoint pages and give me the option as to whether I deny access or not. Fortunately I have found a solution which works for me.
ASP.Net tagMapping
One of the great and underused (at least on my part) features of ASP.Net 2.0 is the <tagMapping> section of web.config. From the documentation…
"Defines a collection of tag types that are remapped to other tag types at compile time"
Essentially this means that you can provide a class which ASP.Net substitutes for the original class when the page is compiled. You can redefine the <ASP:TextBox/> if you want, anything which you can…
a) inherit from the original class and
b) is used within a tag on an ASPX page.
This is extremely powerful and provides endless opportunities for customization. My plan was to provide a tagMapping entry which replaced one of the standard SharePoint controls which is included on all the pages I want to secure.
Firstly I looked at the welcome.ascx control as this is on everyone of the standard SharePoint default pages. Unfortunately there are only two controls used within this ASCX and both of them are sealed. Being sealed means you can inherit from them and therefore cannot map them to a different class (Why?).
So next I looked at the SiteActions control, this is on every page too. This is made up from a FeatureMenuTemplate, which as luck has it is not sealed, so I looked to using this.
Adding security to the WSS pages
To add security checking to all the WSS pages I created a class which inherited from the FeatureMenuTemplate. The code for this is below.
public class SecurityChecker : FeatureMenuTemplate
{
protected override void OnPreRender(EventArgs e)
{
CheckSecurity();
base.OnPreRender(e);
}
private void CheckSecurity()
{
try
{
if (SPContext.Current.Web.CurrentUser == null)
SPUtility.HandleAccessDenied(new Exception("Please login"));
if (!SPContext.Current.Web.UserIsSiteAdmin && !SPContext.Current.Web.UserIsWebAdmin)
{
if (!SPContext.Current.Web.IsCurrentUserMemberOfGroup(SPContext.Current.Web.AssociatedMemberGroup.ID))
SPUtility.HandleAccessDenied(new Exception("You do not have access to this page"));
}
}
catch (Exception ex)
{
Log.Debug(ex.ToString());
SPUtility.HandleAccessDenied(new Exception("You do not have access to this page"));
}
}
}
In this class we check if the user is logged in, if they are not an Administrator and ultimately if they are a member of the site. We then use HandleAccessDenied to get them to either log in, or send them to the standard SharePoint access denied page.
This class is then mapped to the original SharePoint FeatureMenuTemplate class in web.config…
<pages …>
<namespaces …/>
<tagMapping>
<add tagType="System.Web.UI.WebControls.SqlDataSource, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
mappedTagType="Microsoft.SharePoint.WebControls.SPSqlDataSource, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add tagType="Microsoft.SharePoint.WebControls.FeatureMenuTemplate,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c"
mappedTagType="ARF.Web.Controls.SecurityChecker, ARF, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fed9cbb14b1dc0f0" />
</tagMapping>
</pages>
Here we see replacing the FeatureMenuTemplate with the ARF version called SecurityChecker. Now our class will be used and we can check the security.
Now whenever a page is displayed which has the SiteActions menu on it the security will be checked and as the SiteActions menu is on every page all pages will be checked. This example is part of ARF, the source for which can be downloaded from the ARF website.
A note of caution
I am using this with ARF, which has a panel which prevents its child controls from being rendered. I am using this to prevent the SiteActions control being rendered for anyone but site authors in the anonymous master page. Using this prevents the above code being called on the anonymous pages and ensures people still have access to the pages I want them to.
<arf:ARFPanel runat="server" AuthorsOnly="True">
<ARFConsole:Console runat="server"/>
</arf:ARFPanel>
In order to use this WSS security lock down technique you would also need to implement this kind of solution.
Leave a Reply