Microsoft SharePoint Services 2003 has evolved into Microsoft Office SharePoint Server 2007, offering a much fuller, richer security toolset. Whereas SharePoint 2003 relied on logon security backed by Active Directory (AD), portal security, and list-level security, SharePoint 2007 improves previously existing security features while adding auditing features, storage policies, and secure collaboration products such as Excel Services. Let's take a look at how security has evolved in SharePoint, how each version tackles authentication and authorization, and how SharePoint 2007 will benefit your organization.
SharePoint 2003 Authentication
Let's start by taking a closer look at the
security features of Microsoft's SharePoint
2003 products and technologies. The
foundation of any secure product is the
ability to control access to secured materials—which essentially boils down to
digital identity and passwords. Because
SharePoint 2003 technologies rely on AD
to provide user-account validation, the
password policies of any SharePoint site
are basically the password policies of the
underlying AD network. As the Microsoft
SharePoint Products and Technologies
Resource Kit points out, password
policies need to take a host of recommendations into account, particularly
when you're considering the addition of
SharePoint technologies to a network.
These recommendations include minimum
password length, password complexity,
limits on consecutive password attempts,
prohibition of sharing passwords, and
smart card or biometric device usage.
What exactly does the reliance on AD mean in terms of user authentication (verifying that users are who they claim to be)? SharePoint 2003 offers two modes of operation: preexisting-account mode and account-creation mode. In the preexisting-account mode (aka domain mode), an AD account must exist before a user can access a SharePoint site. In the accountcreation mode (selected during SharePoint installation) you can have an AD account automatically created each time you add a new SharePoint user. If you're unsure which mode you're in, you can use the included Stsadm.exe command-line tool to find out.
In either case, the existence of this AD account provides the authentication necessary to access SharePoint. SharePoint validates the existence of the user in AD either through NTLM or Kerberos protocols. To provide authorization, the system compares the authenticated account with a list of access-control information for the SharePoint site itself. These authorization lists are stored in Microsoft SQL Server content databases and are modified from within SharePoint. You can organize these lists or groups at the user level, in site-level groups, or in multisite level groups.
(I've just stated that SharePoint relies on AD to provide account validation, but that's not 100 percent accurate. You can also use local Windows accounts. However, if you don't use AD, you lose the ability to pre-populate the SharePoint profile database. And if any users have personal sites, they won't be registered for cross-farm synchronization in a server farm environment. Because of these severe restrictions, AD environments are highly recommended.)
SharePoint 2003 Authorization
What does the reliance on AD mean in
terms of user authorization (validating
that users have permissions to access
a resource)? SharePoint 2003 authorization is based on groups of rights to which specified users or groups of users
are assigned. You can easily customize
security groups, but by default five security
groups ship with Windows SharePoint
Services:
- Administrator—Wields complete control over the Web site
- Web Designer—Controls the look and feel of the Web site
- Contributor—Can add content to existing Web Parts
- Reader—Has read-only access to content in lists and document libraries
- Guest—Holds the lowest levels of permissions. This group is designed to give read access to sub-portions of a site without giving access to the entire site.
The rights fall into three general categories: list rights, site rights, and personal rights. The system checks list rights to determine whether a user is able to contribute to a list, edit list items, manage columns in a list, and so on. The system checks site rights whenever a user attempts to create a site, manage a site's users, change the look and feel of a site, and more.
The system checks personal rights when a user tries to create or change a personal list view and use private or personal Web Parts. Figure 1 shows the full list of available rights in SharePoint 2003.
After you grasp how your SharePoint system organizes its rights into groups, you'll understand how to organize your users. It's possible to individually manage each user's permissions, but creating groups to hold your users is the recommended best practice. You have two options for grouping your users: site groups and cross-site groups. A site group is a group of users available for assignment on that particular SharePoint site. If your users are grouped in a cross-site group, the system actually creates that group at the top level for the site collection, and it's available to any site in that site collection.
Suppose your organization, Contoso, has several departments, such as Marketing, Executive, Finance, and IT. If each of these departments has its own site under the top-level Contoso site, a user in the Executive department might not have access to documents stored by the Finance department unless he or she is explicitly granted those rights. However, if the users for each department reside in cross-site groups, the manager of the Finance department has to grant only the Executive cross-site group read access to its portal, and all members of the team can be admitted at once.
Site-Level Security
Now, you have groups of users and
groups of rights. What can you do with
these groups to secure the SharePoint
portal? SharePoint 2003 offers two levels
of security: site level and list level.
When you create a SharePoint site, you—as the creator or owner—have a choice about how to handle security. The options are to inherit the permissions of the parent site or to use unique permissions. If you decide to inherit the parent's permissions, the security options flow down to the new portal site and everyone who has any level of access in the parent site has the same level of access in the new site. If you select unique permissions, you are initially the only user given any access to the new portal site. After the site's creation, you can add new users or groups of users to the site and can grant specific permissions.
Suppose your Contoso organization has an IT department. The IT department wants to grant employees the ability to track trouble tickets through their SharePoint issue-tracking list. To that end, the IT department has created an IT portal site off the main Contoso site. In this fictional organization, every member of the domain has at least read access at the main company site. When you created the IT portal site, you did so with inherited permissions; any domain user has the ability to connect to the IT portal site and see the data on the home page, including the issue-tracking list on the IT portal site's home page. Now, the IT department needs to have a location at which it can save IT-specific information, such as server passwords. The IT department doesn't want users to see that this documentation exists, so it has created a new portal site with unique permissions. This PrivateIT portal site might have only members of the IT department as users. When non-IT users attempt to access the PrivateIT portal site, they'll see an error message stating that they don't have permission to access that resource. Optionally, you can have the system prompt them with a message stating that they can ask the administrator to grant them access to the restricted portal.
List-Level Security
List-level security works similarly, but at the individual list level as opposed to the
site level. Consider again the example of
the public IT portal site with its issue-tracking list. Suppose the IT department wants
to give any user the ability to read items
in the list, but the department wants to
give members of the Managers cross-site
group the ability to add new issues and
edit existing issues. In the list's permissions
options, you can add users or groups and assign them various permissions. You
simply enter the list, click Modify Settings
and Columns, and click the Change permissions for this list link. Figure 2 shows
the most granular list of rights available for
assignment. You might notice the tantalizing Modify item-level security link in the left
pane. This link offers you only the ability to
toggle users' views from seeing and editing all entries in the list to seeing only their
own entries in the list.
This item-level permission is a hint of what is to come in SharePoint 2007, which represents a major evolution in terms of authentication and authorization over that which SharePoint 2003 offers. Choices are more diverse, more granular, and more intuitive.
SharePoint 2007 Authentication
In SharePoint 2007, you not only have
the same Windows-integrated options
as before—you also have the ASP.NET provider model. Use of the ASP.NET provider model removes the need for AD or
Windows accounts and gives you new
options, such as forms authentication
against any store of user data (e.g., a
SQL Server database). You also have the
option to use Web-based single sign-on
(SSO) options in which the user is logged
on via a non-SharePoint logon form. A
familiar example of a Web-based SSO
option is Windows Live ID (formerly known
as .NET Passport). This authentication
evolution gives developers and administrators much greater flexibility while installing
and configuring SharePoint 2007.
SharePoint 2007 Authorization
The SharePoint authentication changes
are important, but they're not nearly as
big as the forthcoming authorization
improvements. In SharePoint 2003, users and administrators are concerned
with rights, but in
SharePoint 2007,
the term is permissions, and the
division between
groups of users
and groups of
permissions is
much more clearly
defined. People are
assigned to logical
groups, such as IT
managers, junior
finance employees, and executive
team members. Permissions are
assigned to logical groups, such as designers and readers, and the permissions associated
with those groups are clearly defined. In
SharePoint 2003, distinction is blurred. At
the site level, you might assign a person
to the Readers role, but at the list level,
the Readers group acts more like a rights
specification. In SharePoint 2003, this
dynamic leads to confusion among administrators: Which group of users is allowed
to do what in each site and in each list?
Another major security improvement in SharePoint 2007 is the addition of finer-grained permissions. Now, not only can you secure a site or list, you can also secure a folder and an item in that list. Therefore, you can use the same library to store sensitive documents and publicly available documents. To prevent unauthorized access attempts, SharePoint 2007 offers a security-trimmed interface. If a user doesn't have permission to view a document or menu item, that document or menu selection doesn't even appear to that user. The entire Site Actions menu won't appear if the user doesn't have the required permissions to use any of the menu's elements.
SharePoint Groups are logical groupings or collections of people. Out of the box, the software offers three groups: Owners, Members, and Visitors. These groups function like SharePoint 2003's cross-site groups in that you can assign them anywhere in a site collection and they will be henceforth available for use anywhere in that site collection. These groups let you scale permission assignments across large numbers of people.
The original concept of SharePoint site groups is extremely flexible, making it difficult to effectively organize users and roles. You can assign users to a site group, and you can assign rights to the site group. Then, by assigning the site groups of users to those groups that contain rights, you effectively create a role by defining which users can do specific actions. The new version addresses this ambiguity in the definition and purpose of groups. In SharePoint 2007, the role-based concept of collections of permissions is now clearly defined as a permission level, which functions as a role. You assign permissions to these permission levels, and you assign these permission levels to SharePoint groups.
Groups are also now always defined at the site-collection level, enforcing a consistent naming convention within all the sites of a site collection. All of this reduces the potential for confusion.
Consider a hands-on example. In a SharePoint portal, click the People and Groups link in the Quick Nav bar, which Figure 3, shows. Click More to view all your groups. By doing so, you see that your site has only the default groups available. You want to add two new groups to represent your Contoso IT department users and your Finance department users. Click New, and select New Group from the drop-down list. For the IT department, fill out the form that you see in Figure 4. Notice the permission levels at the bottom of the form. Before you go on to add a group for the Finance department, create a new security permissions level for the Finance users. Back in the list of groups, click Site Permissions to access the screen that Figure 5 shows. On this screen, you can see the permission levels and groups to which the Finance users are assigned, and you can manage the many-to-many relationship between groups and permission levels. You can see that the roles of Read, Contribute, and Full Control (i.e., administration) exist, along with the new SharePoint 2007 levels of Limited Access (equivalent to SharePoint 2003's Guest level) and Approver. To add a new permission level for your Finance team members, click Settings, Permission Levels. A list of available permissions will appear. Click Add a Permission Level to create a new Finance user role. On the screen that Figure 6 shows, you can see how many more permission options are available in SharePoint 2007 than in SharePoint 2003. Select the permissions you want (grant lots of list rights) and click Create. Now, you have a new permission level for Finance department employees. Go back to your Permissions home page and add a new group to contain your actual Finance employees. When you do so, the added Finance user permission group will appear at the bottom of the New Group screen. Now, you can add users to the Finance group, and any user of the Finance group will have the same permissions in any site in the SharePoint site collection.
Now that you understand how to collect users into groups and how to assign the groups various permissions, you can see how you’ll use these groups to secure SharePoint 2007. Just as in SharePoint 2003, you can explicitly grant or deny access to a site or a list, but you now have the additional ability to secure individual list items and document library folders. So, a user might have access to a site and a document library, but you can have individual documents or folders to which the user has no access.
Administrative Security
This has been a discussion of user-level and
site-level security in SharePoint 2003 and
SharePoint 2007. There are additional levels
of security available to SharePoint administrators,
who can also apply security at the
Shared Services level and at the Central
Administration level in SharePoint 2007.
Shared Services isn’t a new concept, but it’s now much more apparent. Essentially, Shared Services administration means that the server-farm administrator can delegate authorization for certain tasks to other users. This capability is handy when users make unwanted changes, such as item deletions (and subsequent Recycle Bin clearing). Now, with delegated user authorization, the user doesn’t have to go to the farm administrator for help.
The final possible level of security configuration in a SharePoint 2007 installation is at the Central Administration level. There are a lot of new administration features at this level, including security policies—a set of permissions that apply everywhere across the farm. These Grant and Deny policies override all other permissions, and you can configure them per Web application and per Web zone. Common examples of security policy use include granting full read access to auditors and denying all write access to anyone in the Internet zone (i.e., Extranet). You can also set up the AD service accounts at this level to prevent unauthorized application behavior on the network. You configure the application pool accounts, the SharePoint service (SPTimer and Admin Service) accounts, and access to SQL Server at this level.
A Powerful Force
SharePoint 2007 is poised to greatly
improve the SharePoint end-user experience.
Thanks to a slicker interface and
features such as security trimming, the
user will see only the sites, lists, and documents
that they have permission to see.
More important, SharePoint 2007 will simplify
the life of the administrator, thanks to
cleanly organized users and roles defined
at one level, the ability to delegate activities
to others via Shared Services, and the
introduction of system-wide security policies.
