Chapter 10: Application Security

• Learn the basics of code access security and trust levels.

• Configure application trust levels by using solution packages.

• Understand WSS authentication and authorization.

• Work with WSS security classes and interfaces.

Introduction

Certainly, security is an important topic when designing and implementing a business solution with Microsoft Windows SharePoint Services (WSS). You don’t want users who haven’t been granted the proper permissions to be able to view or edit sensitive pages, items, or documents. At the same time, you need to ensure that users with the proper permissions can access what they need. Although WSS goes a long way toward providing out-of-the-box security features that allow site owners to configure access rights within a site collection, a WSS developer should know how WSS security works behind the scenes as well as how to extend the WSS security model with custom code.

WSS is very flexible in that it allows users to create and deploy content using Web Parts, thereby avoiding many of the formalities of traditional application development. Although allowing users to add Web Parts to pages on the fly is powerful, it also brings up security concerns because it allows end users (as opposed to administrators or developers) to decide what code runs behind a Web Part page. You have already seen how WSS employs SafeControl settings in the web.config file to ensure that users use only Web Parts that are preapproved by a farm-level administrator. WSS goes one step further when it comes to protecting the system from code within Web Parts that could be malicious or poorly written. The farm-level administrator is able to configure Web Part DLLs so that they run within a restrictive sandbox using trust levels and code access security.

The first part of this chapter covers code access security and shows you how to write and deploy Web Parts that might be deployed in a secure environment. The second part of this chapter discusses how WSS manages security contexts and user identities. As you will see, Web Part code runs under the security context of the current user by default. The application pool identity also plays a role, as well as the identity and trust of the Web Part code itself. Understanding these security contexts and their limitations helps you write effective code.