SharePoint Designer 2007 Governance: Options for selective lockdown?

Stephen from SharePoint Designer Team had lately published a great article about options available to users for locking down SharePoint Designer 2007 (SPD). I review & re-visit that list to evaluate requirements missing, and what can be done by a developer to fill the gap of “selective lockdown”.

SPD governance has been a issue, particularly in large setups and organizations, where farms are de-centrally managed. Central IT team is concerned about governance, users about functionality, and the sweet spot is missing in SPD due to lack of ways to have granular control of what functionality is available to users and what not. Think again and say IT doesn’t want users to modify sites look-and-feel, yet allow them to work on – say – workflows. This is realistic when WSS/MOSS is used in a large farm with hundreds and thousands of sites; they are not centrally managed for permissions and IT is merely managing the platform and it’s hygiene around set policies.

So I’ll summarize in bullet’s what Stephen already covered, and what is missing from his article/solutions. Also what controls we possibly have that we can leverage to build additional, custom, and fine-grained controls.

What we already know from SharePoint Designer Team?

1. Site Definition: Edit onet.xml to lock down all sites in a farm on a per site definition basis – say STS. You have to edit onet’s for each site template; manually or code a xml merging feature for server’s in farm! Once locked, there is no way to make exceptions for any sites using that template in your farm.
2. Permissions at Web App: Central management of permissions, applicable for all sites in a web-app, but with many caveats!
3. Policy for Web App: Create a permission group and target it to specific users or groups for a web-app. No exceptions can be made to sites. Granularity of specific functionality control, remains an issue. Few other caveats given…
4. Site Permissions: Define and manage permissions on a site. Not useful for large farms where central IT governance becomes an issue. On such farms, friends and family can all be site admin’s but central IT is concerned about governance policies and centralized controls.
5. SPD Contributor Settings: Not a secure means, it only allows site-admin’s to define settings for specific actions in SPD. This gets closest to what we endeavour – fine controls over who can do what. Biggest issue here remains – central IT cannot manage them. It has to be defined and managed by site admin’s!
6. Group Policy – per Computer or User: This is most useful since you have control over which options you want to globally (or specifically) hide from being available to users/computers, say you don’t want to give design capabilities but only functional such as workflows. GPs can be applied per user or computer, and only apply to client (SPD) and doesn’t govern permissions on SharePoint.

What is wrong with above approaches?

There are several issues with above approaches though.

1. All or Nothing: No way to granularly block specific functionality available in SPD. Like you want to stop design changes (editing master pages, unghosting home pages), but not functionality: data-views, workflows etc. Or say you don’t want edits to system galleries, unghosting of pages like Home (default.aspx) etc.
2. Exceptions: No way to make exceptions for certain sites when all others are blocked centrally by IT.

What additional options are available?

To meet short-comings or desired requirements for specific controls we can primarily exploit 2 approaches:

• Enable/Disable SPD access on per site-level, in any web-app: This extends upon Onet.xml switch. Sites derive their config from Onet.xml, but can also specialize it for local use. Same trick is applicable for disabling site access from SPD by inserting “vti_disablewebdesignfeatures2”, with value “wdfopensite”, in sites property bag ().

   1: if (web.AllProperties.ContainsKey("vti_disablewebdesignfeatures2")){

   2:     web.AllProperties["vti_disablewebdesignfeatures2"] = "wdfopensite";

   3:     web.Update();

   4: }

   5: else{

   6:     web.AllProperties.Add("vti_disablewebdesignfeatures2", "wdfopensite");

   7:     web.Update();

   8: }

• Not just that, you may use other properties given here.
• Also there is a project on codeplex for getting you started with code. Note that projects implementation is for a single site, but can be modified for centralized manageability for building a tool for Central Admin instead where you can control introduction/removal of property in the sites property bag centrally.
• Govern all change communications from SPD to SharePoint on the server-side: Once we have control over specific sites of choice for enabling/disabling SPD access, we can now get into individual calls made from SPD to SharePoint to intercept those we want to deny.
  • Build a custom .NET HTTP Handler and register in web.config for author.dll as follows: <add verb="*" path="*/_vti_bin/_vti_aut/author.dll" type=”[Your Type]”/>
  • Use fiddler to identify calls of specific actions initiated from SPD. Pattern match such RPC method calls in our handler and return a message of denial. You can even do custom messaging. Store messages and Regex patterns in your config.
  • You can put a simple Xml for config containing calls you want to disable, their denial messages. This can even reside in a list in Central Admin. Read (cache) this config from you handler and decide at runtime on what is allowed.
  • Optionally you can build groups of functionality/denials as policy templates in a list and have another list for association to specific sites. This way you not only have control over which sites get SPD, but also what functionality (via template/policy) within scope of SPD features.

Conclusion

To gain fine control over SPD functionality for SharePoint over specific sites, apart from what SP Designer team has already documented. Site-level access control for SPD, and HTTP handler for SPD XML RPC calls pretty much covers the limitations highlighted and enables specific governance controls one needs in a large farm where central IT is defining policies and farm is decentralized for permission management of individual sites.

Thanks

--Sharad