Authorization, Users, and Groups

  • Article

Applies to: SharePoint Foundation 2010

In Microsoft SharePoint Foundation, 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 SharePoint Foundation objects.

To give a user access to an object, you can add the user to a group that already has permissions on the object, or you can create a role assignment object, set the user for the role assignment, optionally bind the role assignment to the appropriate role definition with base permissions, and then add 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.

Following are ways that SharePoint Foundation provides to control access to its objects:

  • Objects can 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, enabling fine management of user access to objects.

  • Groups consist of users and may or may not be assigned to roles. SharePoint Foundation 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 indirectly through a group that has a role assignment, or directly through a role assignment. Users also 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 through the functionality of the addrole.aspx file and the editrole.aspx file. Unlike these pages presented in the user interface, 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 SharePoint Foundation 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 SharePoint Foundation 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 level or at the zone level. A user can have, for example, different policies on https://Server and http://Server.extranet.microsoft.com, even if the two Web applications have the same content.

Rights can be granted or denied through 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 is given a higher priority than 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. 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.

In This Section

Authorization Object Model

Authorization Object Relations

Role Assignments, Role Definitions, and Inheritance

Impersonation

Elevation of Privilege

Automatic Password Change and Managed Accounts

See Also

Concepts

Authorization and Authentication

SharePoint Claims-Based Identity

Getting Started with Security and Claims-Based Identity Model