Application Security

In the Application Security section, you have the ability to define permissions, rights, and policies for individual Web applications that can restrict the rights the users have throughout the Web application and all its associated sites. Like everything with the security configuration, you must ensure that you select the correct Web application in the management control; otherwise, you might stop valid users from performing their required roles. There are five configurable security options and each plays a different role in applying security at different levels in the Web application. The five options are as follows:

• Security For Web Part Pages

• Self-Service Site Management

• User Permissions For Web Application

• Policy For Web Application

• Authentication Providers

Planning 

Before configuring any of these security options on a Web application, plan and test the configuration first. Many of the settings, such as the user rights for Web applications, can benefit from being implemented before users are added to the site for general access.

Security For Web Part Pages

Web Parts contain Web content such as text and images. Web Part zones are groupings of Web Parts. Web Part zones can also be grouped to form a Web Part page.

Most of the time, the Web Parts serve a single purpose, such as a document library or an announcements list. It is possible, however, to have Web Parts connected to each other to manipulate the data returned by one or several of the Web Parts viewed on the page. This connection enables a user, for example, to select a customer name in one Web Part and then have information only about that customer displayed in the second Web Part. By default, users can create Web Part connections on a page; however, if you do not want this to be possible, you can disable this capability in this screen.

Planning 

There is a performance increase on the Web server when generating views based on connections between Web Parts. Take this into consideration when planning and testing these Web Part connections.

Important 

By preventing Web Part connections, you are preventing all sites associated with the selected Web application from creating connections between Web Parts.

The second option for security in Web Part pages is for accessing the online Web Part gallery. When you want to add a Web Part to a page, you are presented with a default gallery view. However, as a user, and if all galleries are enabled, you can use the advanced view to see all four of the available galleries The online Web Part gallery includes Web Parts such as the MSN weather and stock news, but it does affect the performance of the page when adding Web Parts because the gallery has to go to the online sites to retrieve the list of available Web Parts. If your users do not need access to these Web Parts, it might be worthwhile to disable this option because it speeds up the Web Part gallery retrieval. Also, look at access in terms of security. You might not want the users of a particular Web application to have access to the Internet gallery for security reasons and, therefore, preventing such access can be a security benefit.

Note 

If you do want to use the online gallery but are unable to connect to the site, you might need to configure the outgoing proxy server settings in Central Administration, which informs SharePoint which route to take (such as a Microsoft ISA server) when accessing the Internet for the gallery.

Self-Service Site Management

By default, users cannot create subsites from a top-level team site. This policy gives the site collection administrators the ability to control the growth of top-level sites. When necessary, the site collection administrators can give users the right to create subsites at a lower level only. This control is not always necessary, though, and by enabling the Self-Service Site Creation correctly, you can allow users to create new sites at any level below the site collection top level. Once self service has been enabled, a message is displayed in the announcements list on the home page of any new top-level site collections to inform users that Self-Service Site Creation has been turned on for that site collection.

Note 

Make sure your site collection home page has an announcements list available. Not all site templates have the announcements list by default. Create the announcements Web Part and then enable the Self-Service Site Creation right.

All sites that are created will default to the defined managed path, which is /sites. You can create additional managed paths, however, by using the Define Managed Paths page, which is discussed in the "Define Managed Paths" section in this chapter.

Planning 

It is an important design decision early on to plan which site collections will require the Self-Service Site Creation right and those that will not. It might also have an effect on how many Web applications need to be created, because this right is enabled on a per-Web-application basis.

User Permissions for Web Applications

Three different sets of rights with individual permissions are applied by default to every new Web application created. Every site collection and site created in that Web application inherits these user rights. The user rights are used when creating or editing the rights of a site group. The three available sets of rights are as follows:

• List permissions include the standard rights of a user for viewing, adding, or deleting a list item. The site groups you belong to determine which list permissions you get. A reader, for example, gets the view-item-only right, whereas a contributor also gets the ability to edit and delete items. After a user has been added to a group with contributor rights, these default Web application rights would be applied.

• Site permissions deal with the rights available on sites throughout a site collection, and they include rights such as the right to apply a theme to a site. You might not want any individual who can access your Web application and its sites to have the ability to change a theme to a site, such as changing the site appearance away from the corporate branded theme. By removing the right to apply a theme at the Web-application level, you are able to prevent even the site administrators from having the right by removing the right from all groups in the site collection and sites.

• Personal permissions are rights associated with a user being able to add Web Parts that are specific to the user, such as Web Parts that are available for the My Sites of users. By removing these rights, you could create a uniformed view for all the pages and sites in the Web application that users are not able to personalize or change with their own private content.

Important 

When removing user rights from a Web application, remember that it also affects the administrators of the site collection as well. You cannot choose to have the user right affect only a select group of users in the Web application.

Policy for Web Applications

Policies are a new management tool in SharePoint Server 2007. This tool enables administrators to create a centralized policy mechanism that will affect all top-level site collections and sites configured in the Web application. An administrator creates a centralized policy mechanism to determine the level of rights a user gets when accessing the particular Web application from a certain zone. If a user is accessing a site from the Internet and the Internet zone is set for All Users Full Read, then even if a user has write access to the site, he is restricted from doing so because of the zone he has come through to access the site.

Note 

Zones in a Web application refers to the zones associated with the Alternate Access Mappings. Zones include Default, Intranet, Extranet, Internet, and custom. See Chapter 6 for more information on Zones and Alternate Access Mappings.

Real World Configuring Web Application Policies

Suppose that you have a group of users who work remotely, and they need read-only access to the sites in a Web application. These users will be accessing the Web application from the Internet and, therefore, they will be in the accessing from an Alternate Access Mapping that is defined in the Internet zone. Other users on the local area network (LAN) will be in the Default zone because they are accessing the Web application using the internal URL which is mapped to the Default zone. Using the policy configuration, you can create a new policy for the remote users and configure the necessary permissions. You can choose from the following permissions to apply for the selected zone:

• Full Control

• Full Read

• Deny Write

• Deny All

To configure a policy for users on a Web application, complete the following steps:

1. Select the Web application to which you want to apply the new policy.

2. Choose the zone that the policy is to be applied to. For all users who use Windows authentication, you can select All Zones. In this case, select the Internet zone.

3. Click Next.

4. Type the user, group name, or e-mail address for the policy to be applied to. In this case, you would specify the remote users.

5. Select the specific permission to be applied to the group that matches the zone type-for example, Full Read.

   The final option is to have the user account masked as a system account. This means all actions carried out by the user would be registered as a system account entry rather than the actual user account. A good example of this is if an administrator fixed an issue on a public-facing Internet site and you wanted the account that made the change to be shown as System rather than the actual user's name.

6. Click Finish.

You can create as many policies as you require and therefore control the level of access for many different groups of users accessing the Web application from multiple zones.

Authentication Providers

The authentication provider allows you to change the method with which users are authenticated against the Web application. The default is to authenticate all users using Windows authentication; however, SharePoint Server 2007 now supports multiple authentication provider mechanisms:

• Windows

• Forms

• Web Single Sign-On (SSO)

• Anonymous Access

You can switch your IIS authentication mechanism to either Windows or Basic authentication. When choosing Windows authentication, you also have the option to enable the more secure option of Kerberos instead of NTLM. However, your environment must be able to support this. The final option for configuration here is to disable client integration, which stops certain client applications from launching when connecting via this particular Web application. When client applications are disabled, users have to save their work locally and then use the upload function to add the document to the library.

Configuring Authentication Providers

SharePoint Server 2007 does not let you use two authentication mechanisms on the same Web application. If you require two methods of authenticating to the same content, such as might be needed by external users, you can do the following:

1. Extend and map a new Web application to an existing Web application hosting the content.

2. Change the new Web application to the new authentication mechanism-for example, Forms or Anonymous Access if the content is to be published to all external users.

3. Set publishing rules on your firewall to point to the new Web application for the external users.

To provide a more robust and secure publishing environment, you could use a Microsoft ISA 2006 server in your screened subnet that has the ability to support both forms-based authentication and single sign-on authentication.