Changes in the Authorization Object Model

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 all object scopes share the same basic permissions management experience. Unlike in Windows SharePoint Services 2.0, Windows SharePoint Services 3.0 manages permissions through role definitions, not site groups, which allows a consistent experience at the list, folder, and item level. In Windows SharePoint Services 3.0, the former site groups are mapped to role definitions.

Site Groups

The site group concept is deprecated in Windows SharePoint Services 3.0, and the cross-site group concept assumes a more prominent role: domain groups, for example, can now be members of cross-site groups. Windows SharePoint Services 2.0 did not allow this because of the potential group-nesting problem that results, for example, when a user is a member of a domain group, a cross-site group, and a site group.

Object Model

Windows SharePoint Services 3.0 implements new types in its object model to support the new security model. The following security objects used in the previous version are obsolete but continue to function for backwards compatibility:

• Microsoft.SharePoint.SPPermission

• Microsoft.SharePoint.SPPermissionCollection

• Microsoft.SharePoint.SPRights

• Microsoft.SharePoint.SPRole

• Microsoft.SharePoint.SPRoleCollection

To assign users to roles, instead use members of the new Microsoft.SharePoint.SPRoleAssignment and Microsoft.SharePoint.SPRoleAssignmentCollection classes. The new Microsoft.SharePoint.SPBasePermissions enumeration includes new permissions, in addition to many legacy permissions that map to the same constant values as previous permissions in SPRights. The new SharePoint group concept maps to the existing SPGroup and SPGroupCollection objects that represented cross-site groups.

Web site-level security is easy to map between Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 because a 2.0 site group becomes a 3.0 role definition and a cross-site group. Windows SharePoint Services 2.0 did not support granting rights directly to users on the Web site level, and so the old object model maps directly to the new one.

The upgrade of list-level security from 2.0 to 3.0 proceeds in the following order:

1. Users and groups are assigned permissions to a default role. After upgrade, the user has the same role with the following mappings:

   • Administrator — Full Control

   • Web Designer — Design

   • Contributor — Contribute

   • Reader — Read

   • Guest — Limited Access

2. Users and groups are assigned permissions to a custom role. After upgrade, users have the same role.

3. Users and groups are assigned specific list rights. After upgrade, Windows SharePoint Services generates new roles with the appropriate list rights and assigns users to the new role.

Policy Roles

To create or modify security policies for URL zones, use the following new classes and their members:

• Microsoft.SharePoint.Administration.SPPolicy

• Microsoft.SharePoint.Administration.SPPolicyCollection

• Microsoft.SharePoint.Administration.SPPolicyRole

• Microsoft.SharePoint.Administration.SPPolicyRoleCollection

• Microsoft.SharePoint.Administration.SPPolicy.SPPolicyRoleBindingCollection

• Microsoft.SharePoint.Administration.SPPolicyPermissions

Guest Roles

The concept of a guest role was introduced in the Windows SharePoint Services 2.0 to accommodate the shared resources within the platform. For example, the theme and navigation structure of the Web site must be used to render the page for a list view. This concept continues in Windows SharePoint Services 3.0 and is extended to include folder and list-level permissions.

The Windows SharePoint Services 3.0 object model continues to call this the Guest role for semantic compatibility with the previous object model, although in the user interface the role is now called Limited Access.

Folder and Item Extensions

When a user is granted permissions on a folder, they are also granted the Guest role on the parent list of that folder and on the parent Web site of that list—on every uniquely secured scope above the folder all the way to the first unique ancestor Web site. The same holds true for list items: granting a user permissions on an item also grants that user the Guest role on all parent folders, lists, and Web sites up to the first unique ancestor Web site.

Removing Users

Removing a user from a scope also removes that user from all uniquely secured scopes beneath the current scope. For example, removing a user from a Web site also removes that user from uniquely secured lists in the site.

The only way to remove a user from all scopes is to delete that user from the site collection, which removes the user from all roles in all scopes within the site collection.