In-Depth
Secure Your Intranet
Secure the sites, subsites, content, and Web parts that make your Intranet such a powerful tool, without destroying its usefulness.
If your users depend on Windows SharePoint Services (WSS) and SharePoint Portal Server (SPS), they are collaborating in some fashion. Perhaps your organization has the two servers configured as an Intranet portal, or perhaps your employees just rely on the collaboration features. Regardless of how you have these malleable tools arranged, you need to make sure people see the content appropriate for them and nothing more.
One of the most important aspects of a WSS installation is properly securing the installation. Because SPS is a WSS application, locking it down also requires a thorough understanding of WSS security. In this article, I show how WSS handles authentication and authorization, how to assign WSS administration, and how to set up site and cross-site groups. You'll learn how to secure Web parts, which provide the opportunity to highly customize your portal and therefore must be very secure.
WSS Authentication
Authentication is proving who you are to Windows and IIS. The Web server must determine your identity, and relies on NTLM or Kerberos to handle authentication. Kerberos is available only when using Active Directory (AD). WSS relies on IIS for authentication. While there are four options for authentication, use Integrated Windows Authentication where WSS is serving a site inside your firewall. Integrated Windows Authentication doesn't work through a firewall. Use Basic Authentication with SSL to avoid sending all information, including your password, in clear text.
Because WSS needs to authenticate a user to serve site resources, Anonymous Authentication is turned off. Although it is possible to provide Anonymous Access, there are more bad reasons than good to do so. The biggest downside is a complete lack of permission restriction granularity across your site. It is very important to maintain an audit trail so you can tell who tried to access the site, what resources they tried to access, and what they tried to do with those resources.
Windows authentication results in a token that includes the user's rights at the time of authentication. WSS will then rely on ASP.NET to use this token to determine whether authentication has occurred successfully.
Domain accounts should be used in all cases when configuring server access accounts for both administration and access to the content virtual server. The domain accounts for these servers should be different, separating administrative functions (e.g., creating new content databases) from portal functions (e.g., populating the content database with content).
SQL Server Authentication
WSS stores its data in a SQL Server database. Once we have authenticated with IIS, the next step is to authenticate with SQL Server. Each Web site runs in an Application Pool, and each Application Pool has an Identity. If this is a single server configuration, the Identity user is typically Network Service. If this is a server farm, then a domain account should be set up and used for all of the Web servers in the farm to access the database. Do this for both the administration and content database.
SQL Server allows either Windows or SQL Server Authentication. WSS uses Windows Authentication by default, which is the more secure of the two. Be aware that this is a one-time choice made during installation.
These accounts must be added to SQL Server as logins. Unfortunately, they can't be added using Enterprise Manager, the SQL Server management UI, and must be added using the sp_addlogin stored procedure. Network Service or the domain account for administration must be configured to have access to SQL Server. Once this new login is created in SQL Server and given access to the administration database, it must be given Security Administrators and Database Creators server roles. Then the Network Service or the domain account for the content database must be configured in the same way, though it does not need to be a Security Administrator or a Database Creator. Once this is configured, appropriate users will be correctly authenticated through the whole range of activities required to use the site. If necessary, each content database may also have unique logins, providing a more granular layer of security.
Authorization is allowing a user to perform a specific set of actions with a resource, from restricting access entirely to reading it to full change control. WSS handles all authorization, and has its own authorization scheme. WSS implements the concept of site groups, a role-based permission schema, which have access permissions. These access permissions provide a granular level of control to resource authorization. You can create your own custom site groups by assigning new site groups a custom selection of access permissions. Creating custom site groups allows you to assign custom access permissions to a site as necessary. First, let's look at how to configure WSS Administrators.
WSS Administrators
The first task you will need to do is set up WSS Administrators. The process is relatively easy—create an AD group, add the desired users, and specify this as the WSS Administrator group. By default, the Local Administrator group for the server is also a WSS Administrator group, so the members of the group are WSS Administrators.
WSS Administrators don't have to be administrators of the underlying server to perform WSS-related tasks.
Site Groups
WSS uses site groups to provide authorization to a site. Site groups are designed to provide straightforward management of WSS sites, and their authorization is scoped to the site level. There are seven default site groups: Guest, Reader, Contributor, Web Designer, Administrator, Content Manager, and Member. As mentioned, WSS Administrators have complete control of the Web site. This includes managing users and site groups, configuring site settings, and a variety of other management tasks. Web Designers can customize the Web site. Contributors can work with Web parts, document libraries, lists, views, and Web pages. In particular, they can create personal views and personalize Web parts pages.
Readers can view document libraries, lists, views that have been created, and Web pages. They can also create sites using WSS's Self-Service Site Creation. Content Managers can manage all of the settings and the content in the subsites that they have permissions to. Members can submit listings and create personal sites. Guests are constrained to a specific set of permissions. Guest and Administrator cannot be customized or deleted.
There is also a eighth group, Custom, that allows a custom mix of rights to be assigned. The default access rights of each of the four default site groups can be changed, but this is not recommended. If you need a different set, create a custom group and assign what you need. This is accomplished by going to the Site Settings page for the portal and clicking Manage security and additional settings under the General Settings section. On the Manage security and additional settings page, click Manage site groups under Users and Permissions. On the Manage site groups page click Add a Site Group, then give your custom site group a name and description, and select the rights you want to include for your group. Once this is completed, you can go into the site group and add members.
There are many rights that can be set, and they allow a granular control of permissions (see Table 1). Some rights depend on other rights. Therefore, assigning some rights will mean that WSS will also assign other implied rights. It does this directly on the rights assignment screen so that you are not left guessing.
Cross-Site Groups
WSS has top-level sites and subsites. WSS takes a hierarchical approach to this concept. Each physical server can have any number of virtual servers. Each virtual server can have, in turn, any number of Web site collections and applications. Each Web site collection can have a top-level site and any number of subsites. Each subsite may have nested subsites. From an authorization perspective, these top-level sites are where site groups, and therefore rights, are applied. A subsite can either inherit permissions from the top-level site it is under, or implement a unique set of permissions.
WSS provides cross-site groups as a way to ease user and permission management. Users need different permissions on the sites to which they have access. Managing the assignment of each user, even when using NTLM or AD groups, is time-consuming as WSS site groups insert another security layer between the operating system and the resource. Because site groups are scoped at the site level and therefore can only be assigned at the site level, another solution is needed. Cross-site groups are the answer. Cross-site groups are scoped at the site collection level, not at the virtual server level and, as such, can be added to all top-level sites. Cross-site groups can also be added to site groups. Therefore, users who need a similar set of permissions across the entire site collection can be added to cross-site groups and then those cross-site groups can be added to the appropriate site groups to provide them with the required permissions. Cross-site groups must still be added to every site or site group, but this single-point-of-assignment of rights for an NTML or AD user (or group) can simplify the entire management process significantly.
Let's walk through an example. Sally logs on to her PC, starts IE, and makes a request for the corporate Intranet site. The IE process runs a thread as Sally. IE makes the request to the Web server as Sally. The server process on the Web server is running as Network Service. At this point, the Web server needs to know if Sally can start a thread. Therefore, she has to be authenticated by IIS so that it can determine her rights to access the portal site. If she can't even start a thread, then the Web server will simply deny the request. If she can, then that thread runs as Sally.
Now that Sally is authenticated, part of her request is for a resource—a document. WSS uses the site groups, cross-site groups, and rights to determine whether Sally has the necessary permissions to access the requested resource in the way that she wants to access it. If not, the request is denied. If so, WSS makes a request to SQL Server to get the resource. The SQL Server process runs as a Local System or a custom account. The thread that was started in response to the Web server's request is running a Network Service—not as Sally. Therefore, Network Service must have the appropriate authentication and authorization rights for SQL Server. Once SQL Server receives the request, it fulfills it by returning the resource to WSS. WSS packages the resource and sends it to IIS, which then sends the response to Sally.
Locking Down a Site
Now that we have explored authentication and authorization, let's lock down a site. First, we need to assign the administrators group. I use an AD group that is not an administrators group on the server. Second, I create my top-level site. This will be the intranet site for my firm. Therefore, I give permissions to an AD group that includes everyone in the company. I select the Reader role for them. Third, I create the other site groups and custom site groups that I need, apply the correct rights, create subsites, and assign those groups to the subsites.
Once you secure the top-level site, subsites, lists, and document libraries, you need to provide access to additional information sources to make your site a true portal. One way to access and expose data from back-office systems (e.g., accounts payable), personal productivity tools (timesheets), and external information (weather reports, news feeds, and partner information) is with Web parts. Web parts are building blocks that make WSS a powerful portal solution. There are a number included in the box, and you can build you own Web parts easily using the .NET Framework.
The SharePointhandler object builds Web part pages dynamically. Web part pages, as well as any customization and personalization, are stored in the content database that WSS is using for your site. Content is dynamically loaded by the dlls. This introduces some significant security risks, as the database is directly exposed to the Web.
Therefore, restrictions have been placed on Web parts to make them more secure. For starters, inline code can't be placed in a Web part. Restricting the use of inline code prevents script hacking as all code must be compiled into a dll. The dll could still be malicious, but administrator rights (not WSS rights) for the server are required to install the Web part. Further, Web parts must also be marked as safe controls. These restrictions provide a significant level of protection in an environment that would otherwise be insecure.
Code Access Security
Think of Web parts as mini applications that are downloaded to a PC and run on the desktop. Web parts need to be "sandboxed" or "quarantined" within WSS using Code Access Security (CAS), which prevents registry read and write operations and file system access.
To see why CAS is necessary, let's look at how Web parts are executed in the traditional Windows security model. As we saw, a process starts a thread and that thread executes with the identity and permissions of the user. This is fine if you are running in an entirely contained environment such as a traditional client/server, where you have total control over all code. However, when you download Web parts from a variety of companies and partially trusted sites, this model presents problems. When a user views the portal site, a Web part may piggyback with a page load. This Web part executes a process that starts a thread that runs unknown code against corporate assets. This unknown code would be running with the identity and permissions of the user who opened the Web portal page.
For example, let's say an employee with administrator permissions uses a newsfeed Web part. Serious consequences could occur if the Web part contains code that accesses sensitive systems.
CAS is a component-level security model layered on top of Windows security. It is implemented as part of the .NET Framework and addresses the issues discussed above by allowing code from different sources to be handled uniquely. CAS allows code running from the local hard drive wide latitude while placing more restrictions on code from your intranet. Finally, code from the Internet is highly restricted. Code loaded from the Global Assembly Cache (GAC) has full permissions, whereas code loaded from the bin directory of a site has restricted permissions.
The Common Language Runtime (CLR) interrogates the assembly to discover where it came from and its producer. Code from each origin and producer, including code from partially trusted sites, can be configured to run with individual, custom permissions. Code from unknown origins runs in a highly restricted sandbox.
CAS not only protects the environment in which the code is running, but it allows the code to specify its own needs. CAS allows code to specify the permissions that it requires to run, the permissions its executables must have, and whether they must have a digital signature.
CAS can be configured in two ways. First, WSS provides object model classes for permission handling. The SharePointPermission class contains the ObjectModel and UnsafeSaveOnGet properties. The first indicates whether the use of the object model is allowed while the second indicates whether saving to the SharePoint database is allowed during an HTTP Get request. The WebPartPermission class includes a Connections property that indicates whether Web part connections—Web parts talking to each other—are allowed.
WSS also adds trust levels to those that CAS ships with. These are WSS_Minimal, which is the default, and WSS_Medium. When a WSS virtual server is first created, WSS_Minimal is applied by default. Full trust is given to the GAC, $CodeGen, _layouts, and _vti_bin roots. Partial trust is given to the virtual server's bin directory.
The trust levels are Full, High, Medium, WSS_Medium, Low, Minimal, and WSS_Minimal. The ASP.NET default levels are High, Medium, Low, and Minimal, so some of the CAS permissions will not be granted if the trust level is set to one of these. Specifically, SharePointPermission and WebPartPermission will not be granted, which would disable use of the SharePoint object model and some Web part functionality, respectively.
To change the trust level of a virtual server, open the Web.config file and look for the trust tag:
<trust level="CASLevel" originUrl="" />
Then change the level to one of the seven, save the Web.config file, and perform an issreset.
Custom levels can be configured. This is accomplished by performing the following steps. Start by making a copy of the WSS_Minimal policy. The WSS_Minimal policy file is located at installdrive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\config\wss_minimaltrust.config. Place the copied file wherever you would like and open it. Define a reference to all necessary security classes under the <SecurityClasses> node. For instance:
<SecurityClasses>
<SecurityClass;
Name="RequiredClassName"
Description="MyDescription,
Version=XXXX, Culture=XXXX,
PublicKeyToken=publickeytoken"/>
</SecurityClasses>
Obtain the publickeytoken using:
sn -T assemblypath
from the command prompt. Next, find an existing permission set, such as the ASP.NET permission set, and copy it:
<NamedPermissionSets>
<PermissionSet
class="NamedPermissionSet" Version="1"
Name="ASP.NET"/>
</NamedPermissionSets>
So that you end up with:
<NamedPermissionSets>
<PermissionSet
class="NamedPermissionSet" Version="1"
Name="ASP.NET"/>
<PermissionSet class="
NamedPermissionSet" Version="1" Name=
"CustomPermissionSet"/>
</NamedPermissionSets>
Now edit the Permission Set to include a reference to the Security Class defined above:
<NamedPermissionSets>
<PermissionSet
class="NamedPermissionSet" Version="1"
Name="ASP.NET"/>
<PermissionSet class="
NamedPermissionSet" Version="1" Name=
"CustomPermissionSet">
<IPermission class="
RequiredClassName"
version="versionnumber"
ObjectModel="True"/>
</PermissionSet>
</NamedPermissionSets>
The final step of creating a policy file is to create a code group that assigns the permissions to the desired assembly:
<CodeGroup
class="FirstMatchCodeGroup" version="1"
PermissionSetName="AllCode">
<ImembershipCondition
class="AllMembershipCondition"
version="1" />
<CodeGroup class="UnionCodeGroup"
version="1" PermissionSetName="
CustomPermissionSet">
<ImembershipCondition
class="StrongNameMembershipCondition"
version="versionnumber"
PublicKeyBlob="publickeyblob"
name="assemblyname"/>
</CodeGroup>
</CodeGroup>
Use the secutil tool to retrieve the publickeyblob value from the command line:
secutil.exe -hex -s assemblyname
Save the policy file and it is ready to be used. The last two steps are completed in the Web.config for the virtual server. First, find the <securityPolicy> node and add a <trustLevel> node:
<securityPolicy>
<trustLevel name="
CustomPermissionSet"
policyFile="policyfilepathandname" />
</securityPolicy>
Finally, change the trust level in the Web.config as detailed above. Remember to run iisreset.
How to Deploy Custom Web Parts
The process for deploying custom Web parts is straightforward but has a few steps that must be accomplished in order. First, we will go over manual deployment of Web parts. The Web part description file is an XML file that has a DWP extension and contains basic information about the Web part. The dwp files contain assembly information, and this information is also used in the Web.config to register the assembly.
In your Visual Studio 2003 project, you would add a dwp file to your Web part project. This file will have the following structure:
<?xml version="1.0" encoding="UTF-8"?>
<WebPart
xmlns="http://schemas.microsoft.com/WebP
art/V2>
<Title>YourWebPart</Title>
<Description>Description of
YourWebpart</Description>
<Assembly>YourWebPartDllName</Assembly>
<TypeName>
YourWebPartDllName.YourWebPartName</TypeName>
</WebPart>
Now open a command prompt and generate a public key pair by typing:
sn -k c:\keypair.snk
Open the AssemblyInfo.cs (or .vb) file in your VS2003 project and find the AssemblyKeyFile section and update the AssemblyKeyFile line based on the public key file you just created:
[assembly: AssemblyKeyFile(@"filepath")]
Now find the AssemblyVersion line, which should look like this:
[assembly:
AssemblyVersion("versionnumber")]
Write the version number down. Right-click your project in the Solution Explorer window and select Properties. Select Configuration Properties->Build from the left pane and enter the Output Path that is the bin directory of the virtual server. This will typically be c:\inetpub\wwwroot\bin. Now build your project. This will place the assembly in the bin directory of the virtual server.
Go back to the command prompt and retrieve the public key value of the new assembly. Do this by typing:
sn -T assemblypath
which in the example above is:
sn -T
c:\inetpub\wwwroot\bin\YourWebPartDllName.dll
For later reference, write the public key value (publickeyvalue). Finally, register the assembly with the Web.config file for the virtual server. In this case, the Web.config file would be located at c:\inetpub\wwwroot\Web.config. To register the assembly, open the Web.config file and within the <SafeControls> section, enter the following on a single line:
<SafeControl
Assembly="YourWebPartDllName, Version=
versionnumber, Culture=neutral,
PublicKeyToken= publickeyvalue"
Namespace=" YourWebPartDllName"
TypeName="*" Safe="True" />
Save the Web.config file and run iisreset. At this point, your control will be available to appropriate users with the site and subsites.
Deployment can be automated and made easier to manage with a Web part package. The package uses the manifest.xml to handle the assembly information and point to each dwp file. The package may contain one or more Web part dlls. There will be one dwp file per Web part class. By packaging the Web parts into cab files, the Web part can be installed into the GAC or virtual site's bin directory. To be installed into the GAC, the Web part must have a strong name. In fact, if the Web part dll does not have a strong name, the stsadmin tool will install the dll in the virtual directory's bin automatically. Another added benefit is that resources can be deployed in this manner.
Accomplish all of this magic using the stsadmin command-line tool. Located in the installdrive\Program Files\Common Files\Microsoft Shared\Web server extensions\60\bin directory, this tool installs the cab file, places the dll(s) in the GAC or virtual site's bin directory, and modifies the Web.config file appropriately.
To accomplish this, add a CAB Deployment project to your Web part solution. Make sure it includes the manifest file and appropriate dwp files, as well as any resources your Web part needs. Right-click your CAB project in the Solution Explorer window and specify the file name and path in the Output filename property setting (cabfilepathandname), then build the solution.
Now that you created the CAB file, open a command prompt and type:
stsadmin -o addwppack -filename
"cabfilepathandname"
This step will handle all of the steps noted above, resulting in a Web part correctly installed and registered with the correct permissions in Web.config.
WSS and SPS are user-friendly applications that make deploying portals and collaborative platforms relatively straightforward. With all of that ease of use and power comes the ability to carefully secure content and functionality to protect corporate assets and information.