Users, Groups, and Authorization
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
In Windows SharePoint Services 3.0, access to Web sites, lists, folders, and list items is controlled through a role-based membership system by which users are assigned to roles that authorize their access to Windows SharePoint Services objects.
To give a user access to an object, you can do so either by adding the user to a group that already has permissions on the object, or by creating a role assignment object, setting the user for the role assignment, optionally binding the role assignment to the appropriate role definition with base permissions, and then adding the assignment to the collection of role assignments for the list item, folder, list, or Web site. If you do not bind the role assignment to a role definition when assigning a user to a role, the user has no permission.
Windows SharePoint Services provides the following ways to control access to its objects:
Objects can either use the same permissions as the parent Web site, list, or folder, inheriting both the roles and users available on the parent object, or they can use unique permissions.
Sites, lists, folders, and items each provide role assignment collections, allowing fine management of user access to objects.
In Windows SharePoint Services 3.0, there is only one kind of group, previously called a cross-site group. Groups consist of users and may or may not be assigned to roles. Windows SharePoint Services includes the following three groups by default:
owners (administrator)
members (contributor)
visitors (reader)
When you create a Web site with unique permissions through the user interface, you are directed to a page where you can assign users to these groups as part of provisioning the site.
Anonymous access allows users to contribute anonymously to lists and surveys, or to view pages anonymously. You can also grant access to "all authenticated users" to allow all members of your domain to access a Web site without having to enable anonymous access.
Site creation rights (CreateSSCSite and ManageSubwebs) control whether users can create top-level Web sites, subsites, or workspaces.
Users become members of a SharePoint object either indirectly through a group that has a role assignment, or directly through a role assignment. In addition, users can be members of a Microsoft Windows NT Domain Group that is added to a group or to a role. A role definition associates a user or group with a single right or set of rights corresponding to values of the Microsoft.SharePoint.SPBasePermissions enumeration. Each user or group has a unique member ID.
You can use the object model to create or modify role assignments and definitions differently than you can via the functionality of the files addrole.aspx and editrole.aspx. Unlike these pages presented in the UI, the object model does not enforce rights dependency, so you can create a role definition with an arbitrary combination of rights. However, plan carefully when using the object model to customize role definitions and permissions, because a poorly conceived role definition and inappropriately assigned rights can lead to an unpleasant user experience.
For more information about Windows SharePoint Services rights, see SPBasePermissions.
Security Policy
A security policy provides a means to enforce uniform security throughout all site collections within a Web application (virtual server). Through policy you can assign a role, or collection of rights, to individual Windows SharePoint Services users, and to domain groups using Windows authentication or pluggable authentication systems, but not to SharePoint groups. Each policy entry specifies rights for a user or group in the Web application.
Policy is set at the logical Web application or zone level. A user can have, for example, different policies on http://Server and http://Server.extranet.microsoft.com, even if the two Web applications have the same content.
Rights can be granted or denied via policy. Granting a right gives that right to the user or group on all secured objects within the Web application regardless of local permissions on the object. Denying a right trumps granting the right, actively blocking that right for the user or group on all secured objects within the Web application. Denying all for a user prevents that user from accessing any content, even if the user has explicit permissions on specific content: policy overrides site-level permissions.
In policy roles, the users and groups are identified by both their security identifier (SID) and their login or user name. Applying a policy role is similar to managing permissions for a Web site, list, folder, or document: you add users or groups and assign them to one or more role definitions. However, unlike permissions on Windows SharePoint Services objects, policy roles are not shared with other Web applications or with the content role definitions that are used to manage the permissions on objects. Each Web application has its own policy roles. Another difference between policy roles and managing permissions is that central administrators can deny a right to a user throughout a Web application.
Note
Central administration policy roles differ from the role definitions for a site collection.
See Also
Concepts
Authorization and Authentication
Changes in the Authorization Object Model