Every SharePoint site needs security to ensure users are limited to performing just the tasks they ought to be performing. You would not want an unauthorized employee viewing the Human Resources files, nor would you want a nonemployee accessing certain corporate documents. Security policies dictate user access, user rights, and user permissions. Windows SharePoint Services incorporates a flexible and dynamic security model that allows administrators and users to control access to their pages with ease.
In this chapter, you will learn how Windows SharePoint Services authenticates users and grants permissions. This chapter provides detailed steps and overviews on:
User and site group management
Assigning roles to objects and sites
Once you have completed this chapter, you should understand how to secure a SharePoint team site.
Users access SharePoint sites to add, view, edit, and delete content. To ensure users retrieve the appropriate content, Windows SharePoint Services provides you with a flexible security model. Whenever you work with security, you have to consider two separate but equally important processes:
The process of authentication determines whether a user is who he says he is. Authentication generally involves comparing a username and password to a set of stored credentials. The credentials prove that the user accessing your site is a legitimate user.
Once you have authenticated a user, the next step is to decide which resources the user can access. This process is known as authorization. In most cases, configuring authorization requires that a site administrator map a user to a permission set.
Windows SharePoint Services supports authentication through easily configurable integration with Windows Server 2003, Active Directory, and Microsoft Internet Information Services (IIS). Authorization, on the other hand, requires that you create site groups (permission sets) linked to one or more users. A site group is assigned to a user when the user initially accesses the site. You can also change the site group a user belongs to through SharePoint’s site settings. This process is outlined in Section 4.3 later in this chapter.
Windows SharePoint Services simplifies user management by relying on IIS and Microsoft Windows Server 2003 to manage user accounts and authentication. Either Windows Server 2003 or Active Directory can be used to manage the user accounts; however, IIS is always used to manage user authentication.
Windows SharePoint Services provides two user administration modes:
Domain account mode
Active Directory account creation mode
When you or your administrator installs and configures Windows SharePoint Services on a department or company server, you choose the account mode to use in SharePoint. This is an important decision—once you select one mode, you cannot change back to the other mode without uninstalling and reinstalling Windows SharePoint Services. Further, SharePoint will not run in a mixed mode.
A default Windows SharePoint Services installation uses domain account mode. Domain account mode allows users with Windows Domain accounts access to your site. This account mode is best suited when you plan to use SharePoint internally on a Windows-based network where your systems administrator controls user creation.
If you plan to use SharePoint externally, choose Active Directory account creation mode. In Active Directory account creation mode, you can create users in the SharePoint central administration web site. SharePoint then adds the user to Active Directory after creation.
SharePoint limits which users can access a team site through authentication. Granting a user access to a site means the user passed authentication. Denying a user access to a site means the user failed authentication. Windows SharePoint Services uses IIS to control how a user is authenticated. IIS provides four authentication methods (in order of increasing security):
This mode grants all users access to a SharePoint site. Anonymous access contains no advance security features. You should restrict the use of this mode to external SharePoint sites while securing all internal documents against access from anonymous users.
More secure than anonymous authentication, basic authentication requires all users to provide credentials prior to accessing the site. However, transmitting the credentials poses a security risk. Credentials are passed along the network in clear text, with no encryption provided. Like anonymous access, use of this authentication mode should be restricted.
This is the default authentication mode. A user provides her Windows domain account to access a SharePoint site. If a user does not have a Windows domain account, IIS prompts the user to enter a username and password.
Certificates authentication uses SSL certificates to authenticate a user. To implement this mode, you need to configure both IIS and Windows SharePoint Services to accept certificates, which must be generated by a certificate authority such as Verisign or Thwate.
You can choose any of the four authentication methods, depending on the security needs for your site.
After authenticating a user, SharePoint assigns a default set of permissions to the user. By default, new users receive the site group reader (see the Section 4.3). You can change this setting and grant increased access rights or even grant administrative rights. You can also create different sets of rites for different users or user groups.
Site groups allow you to grant roles to users and groups. You can think of a site group as a set of permissions that restrict what tasks a user can and cannot perform within your SharePoint site. As a site administrator, you can create specific site groups for specific users and functions. Once you have your site group created, you can link it to either a specific user or a specific group.
SharePoint installs five default site groups that you can apply in most situations. Each of the default groups allows different permissions that are useful for different types of users. However, if the default groups do not suit your needs, you can also create custom groups.
The guest site group provides the lowest possible permission level to users without denying site access. This group restricts users and user groups to read-only access. You should use this site group for default users and groups that are not assigned to a site group with greater access rights.
The reader site group has more access than the guest site group. A reader has permission to:
Read all content in the site.
Create a new site using the “Self-Service Site Creation” option. Self-service site creation allows a user to create a new top-level site. When a user creates a new site, he becomes the administrator of that site but still maintains his existing site groups for other areas in SharePoint.
A user assigned to the reader site group cannot make modifications to content on the site. You assign this site group to users and groups who need access to content on the site but do not need to modify the content.
The contributor site group inherits the reader site group permissions, plus the ability to:
Add, modify, and delete content in existing document libraries and lists
Manage personal views
Add and remove personal Web Parts
Create cross-site groups
A contributor cannot create a document library; however, he can add content to, delete content from, or modify content on an existing library.
You should assign this site group to users and groups who need full control over content in document libraries and lists.
The web designer site group inherits the contributor site group permissions, plus the ability to:
Manage lists and document libraries
Create and modify web pages
Manage themes and borders
Apply style sheets to the site
The web designer site group provides advanced control over a SharePoint site, without granting full administrative control. You should assign this site group to users and groups who are taking ownership of a SharePoint site. Keep in mind that a user in the web designer group does not have full administrative control, although she does have great power over how the site is organized and maintained.
The final default site group, administrator, inherits the web designer site group permissions, plus the ability to:
Manage groups for the site
Create workspace sites
Manage list permissions
View usage analysis data
You cannot delete or customize the administrator site group, and one user must always be assigned to this group. You should only grant this permission type to users who are going to control access to sites. Generally, this role is reserved for system administrators and other users who have full trust within an organization. Most users do not need any rights higher than the web designer group.
By default, SharePoint assigns users to site groups. To change the default site group that the user receives, modify the Anonymous Access settings on the Site Settings screen. To modify these settings, follow the following steps:
Click Site Settings at the top of the screen.
Click on the link Go to Site Administration under the heading Administration.
Click on the link Manage Anonymous Access under the heading Users and Permissions.
Under the section All Authenticated Users, you can change the drop-down list to a new default site group.
Figure 4-1 shows the Change Anonymous Access Settings page, which is used to assign users to specific site groups and to determine what access anonymous users are granted.
You can change a user’s site group assignment. Site groups are assigned at three levels:
The Section 4.4 discusses these topics in detail.
The default site groups do not solve every situation. To provide maximum flexibility, Windows SharePoint Services lets you to create, modify, and delete site groups. By allowing customization of site groups, SharePoint allows you to create a flexible security architecture that adapts to your business requirements.
You can assign multiple site groups to a user. If two site groups conflict, the site group that applies to the immediate content being viewed is applied. For instance, you could assign a user to the reader site group for the corporate Human Resources SharePoint team site, the web designer site group for the Training SharePoint team site, and the contributor site group everywhere else. In this scenario, when a user accesses the Human Resources site, two site groups conflict: reader and contributor. Because the user is viewing the Human Resources site (the most immediate content), he will have reader access and the contributor site group will not be valid.
In order to understand how site groups and user assignments work together to provide full security, you must understand the overall security architecture built into Web Parts and Windows SharePoint Services.
Windows SharePoint Services handles security in order of priority:
Use object-level permissions, if they exist.
Use site-level permissions if no object-level permissions exist.
Use global-level permissions if no other permissions exist.
SharePoint assigns global permissions when a user enters SharePoint for the first time. Users receive site-level permissions when they access a site. Generally, a user who doesn’t belong to the administrative group receives reader permissions when he accesses a SharePoint site.
The amount of site access a user requires depends on the tasks the user needs to perform. For example, if a user needs to add content to the team site, she requires the appropriate access rights to do so. To grant these permissions, you need to assign users to a site group to control site access.
Add and delete users and control a user’s access to the site.
Add, delete, and modify the permissions available to a site group.
Enable or disable anonymous access and decide the default site group to which users should be assigned.
Add, modify, and delete cross-site groups.
Allow users to send requests for access to functionality within a site to which they are denied.
To assign a user to a site group permission set for a site, you need to:
Click the Site Settings link on the top menu bar.
Select Manage Users.
Click on the user to modify access rights for the selected user.
Click the checkbox associated with the site group to assign the user to that group.
Figure 4-2 shows the Edit Site Group Membership page for a team site.
You can assign more than one site group to a user for a site. This is useful when you have site groups that do not inherit permissions (for example, a read-only site group, an add-only site group, and a delete-only site group).
Site-level permissions handle many of your security requirements. However, a user may require different access rights to specific content within a site. To increase the flexibility of the security model, Windows SharePoint Services allows you to assign object-level permissions.
Object-level permissions permit a more flexible and dynamic layer of security for users and groups. Whereas a user may require the web designer permission for the entire site, that same user may be assigned reader access to a specific document library. The user can do everything allowed by the web designer group; however, once the user accesses the document library in the site, the user is restricted to the rights that apply to the reader role. This sort of scenario is quite common when you have a site developer supporting a sensitive team site (such as a financial information site or human resources site).
To control access to an object, you need to assign users a site group permission to that object. To assign a user site group permission for an object, you need to:
Select the object that requires additional permissions.
Click on the “Modify settings and columns” link.
Select “Change permissions.”
Select the user to change his permissions.
Choose the appropriate permission level and click OK.
Figure 4-3 shows the Modify Permissions page for the Shared Documents object.
To prevent a user access to an object, perform the following steps on the Change Permissions screen:
Click on the checkbox beside each user you wish to remove.
Click Remove Selected Users.
Removing a user from an object only affects the user’s ability to access that particular object. The user’s site access permissions are not affected. You might, for example, grant the web developer role for a user who helps administer the Human Resources team site, but you might block his access to the Employee Evaluation document library.