By Christian Holslin

Part 1: The Business Case and Step-by-Step Summary

Introduction

If you have ever found yourself the caretaker of a SharePoint farm you have probably pondered an appropriate strategy for governance.  SharePoint offers excellent governance options for its own content, but what happens when you introduce customizations into the environment?

Event Receivers and Workflows are bound to the same security constraints as the items they operate against, with programmable exceptions, but cannot be explicitly invoked without the user possessing the appropriate rights to the item itself in the first place.

Web Services and Governance

Classic ASP.NET Web Services, on the other hand, are a bit more lax in their security policy.  Deploying a Web Service to SharePoint provides many valuable options:

• Automate repetitive and/or labor-intensive operations
• Provide data to web parts and forms
• Interoperate with .NET or 3^rd party applications
• Feed data to SharePoint

The list goes on and on.  When you deploy a classic MyService.asmx Web Service to the “Layouts” folder, it can be accessed and invoked from any Web Application in your entire farm.  Doing so may introduce a security risk by exposing privileged operations to an unintentionally wide audience, especially if your farm has extranet users.

In order to solve this issue so that we can all continue using these types of Web Services, I have devised a methodology for securely packaging and deploying ASP.NET Web Services (those ASMX files we all know about), to a SharePoint farm, without exposing their operations (or the ability to invoke them) to the farm’s entire user community.

And, best of all, you can do this with a regular Visual Studio 2010 SharePoint project (no funny business!).

Business Case

Applicability

This deployment technique applies to single-server and multi-server SharePoint farms.  Both types of farms are subject to the same exposure of privileged operations with a Web Service deployed to the “Layouts” folder.

Web Services

Why do we care?  We, as in Gig Werks, you, .NET applications, vendors, developers, many COTS software titles, all consume Web Services (if you aren’t in this list, I can recommend many other interesting blog posts).  We use them because they are easy to develop, easy to deploy, easy to consume, and allow (basically) any .NET application to perform server-side SharePoint operations.

Open Visual Studio, add a web reference, and you’re off to the races.

While interoperating with SharePoint, for example with InfoPath or a custom Web Part, you may create a Web Service to function as a data source or proxy into another line-of-business system.  You may create a Web Service to perform operations on SharePoint list items.  You may create a Web Service to automate provisioning SharePoint content (e.g. sites).  You may create a Web Service which performs a CPU- or I/O-intensive operation.  If your Web Service falls into any of these categories, you will benefit from this deployment method by providing a secure, discrete access point.

Governance

There’s always a business case for governance, but specifically with Web Services, assuming that you’ve already decided to use Web Services with SharePoint, here are some key benefits to this particular deployment approach:

·     Guard privileged operations from unauthorized access with multiple techniques

o   Use SharePoint’s security infrastructure to protect your Web Services

o   Firewalls

o   Non-standard ports

o   Non-routable URLs

·     Off-load intensive operations to other servers

·     Update Web Service code during business hours without affecting other SharePoint sites

But most importantly, if you’re looking to heavily secure your SharePoint Farm’s custom Web Services infrastructure, this post is for you.

Deployment Technique

To successfully implement this practice, use the following techniques when deploying your Web Service.

Dedicated Web Application

The whole topology starts with a dedicated web application running on a non-standard port accessible via a non-routable URL.  Example:

• http://myserver:32837/_layouts/MyWebServiceProject/Service.asmx

This URL can only be accessed from within the private network perimeter of the same top-level domain (TLD) as the SharePoint server itself, as opposed to the Internet.  This means a user outside the network cannot access this web application at all.  This is what I mean by “non-routable URL.”

I am assuming:

1. Your server hostname is not registered on an Internet-facing DNS server
2. The port is blocked from access by a firewall at the network perimeter, if your server has an Internet-routable address

Most of the time, both of those assumptions are true, but regardless it’s important we understand they are assumptions.

Dedicated IPv4/v6 Address

Additionally, if your server is in a DMZ, or directly Internet-routable for whatever reason, you can always bind the dedicated Web Application to a private IP address on a private subnet (you might have to give your server one first):

Above is the dialog box for the IIS 7 web site bindings editor where you can specify on what IP addresses and ports your Web Services SharePoint web application should respond.  Remember, SharePoint sites don’t have to respond on every subnet.

Assembly Deployment Target: Web Application

The Web Service itself is deployed using a standard Visual Studio 2010 SharePoint project which targets the Web Application, not the Global Assembly Cache, for its .NET assembly DLL.

This one setting is crucial for the entire operation to work successfully.

If you’ve ever thought twice about deploying your code to the GAC, this is at least one reason not to.  The screen shot above is the Property Window for the Visual Studio 2010 SharePoint Project itself, not the Package (or the Feature, because there is no Feature).

Our Visual Studio 2010 SharePoint Project does not require a Feature because once it’s deployed to a specific Web Application via Central Administration or PowerShell, the MyService.asmx file and .NET assembly DLL are immediately available for consumption.  And that’s all our Web Service really is.

Part 1 Summary

So, using those techniques you can setup a private custom Web Service in your SharePoint Farm.  In Part 2, coming out soon, I will show you how to actually create a Web Service from scratch, deploy it to SharePoint using these techniques, and consume it from another custom application.

Please look for part two in the next couple weeks!

By Christian Holslin