共用方式為

Authorization and Authentication

  • 發行項

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.

Windows SharePoint Services 3.0 supports security for user access at the Web site, list, list or library folder, and item levels. Security management is role-based at all levels, providing coherent security management across the Windows SharePoint Services platform with a consistent role-based user interface and object model for assigning permissions on objects. As a result, list-level, folder-level, or item-level security implements the same user model as Web site-level security, making it easier to manage user and group rights throughout a Web site. Windows SharePoint Services also supports unique permissions on the folders and items contained within lists and document libraries.

Authorization refers to the process by which Windows SharePoint Services provides security for Web sites, lists, folders, or items by determining which users can perform specific actions on a given object. The authorization process assumes that the user has already been authenticated, which refers to the process by which Windows SharePoint Services identifies the current user. Windows SharePoint Services does not implement its own system for authentication or identity management, but instead relies solely on external systems, whether Microsoft Windows or non-Windows authentication.

Windows SharePoint Services supports the following types of authentication:

  • Windows: All Microsoft Internet Information Services (IIS) and Windows authentication integration options, including Basic, Digest, Certificates, Windows NT LAN Manager (NTLM), and Kerberos. Windows authentication allows IIS to perform the authentication for Windows SharePoint Services.

    Important

    If you install "Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)," custom solutions may fail if they call the SharePoint object model while impersonation is suspended. If you use Windows authentication and your code calls the SharePoint object model from an IIS worker process, the request must impersonate the calling user’s identity. Windows SharePoint Services configures ASP.NET to impersonate the calling user automatically, but your code may work unexpectedly, or fail, if you suspend impersonation--for example, by calling the RevertToSelf function of the Windows API, or by calling the System.Security.Principal.WindowsIdentity.Impersonate method and passing IntPtr.Zero as the value of the user token parameter. Even if your code does not explicitly revert to self, it might be called by ASP.NET after it reverts to self, such as happens when implementing a virtual path provider; if your code does not impersonate the calling user, it might not function properly.

  • ASP.NET Forms: A non-Windows identity management system that uses the pluggable Microsoft ASP.NET forms-based authentication system. This mode allows Windows SharePoint Services to work with a variety of identity management systems, including externally defined groups or roles such as Lightweight Directory Access Protocol (LDAP) and light-weight database identity management systems. Forms authentication allows ASP.NET to perform the authentication for Windows SharePoint Services, often involving redirect to a log-on page.

  • Delegated: A system for delegating end-user credentials from a trusted system to Windows SharePoint Services. This allows trusted services to pass user identities to Windows SharePoint Services for authorization, conveying who the current user is without requiring that Windows SharePoint Services have that user's credentials.

Note

Windows SharePoint Services does not support working with a case-sensitive membership provider and uses case-insensitive SQL storage for all users in the database regardless of the membership provider.

Forms-Based Authentication

Forms-based authentication provides custom identity management in Windows SharePoint Services by implementing a membership provider, which defines interfaces for identifying and authenticating individual users, and a role manager, which defines interfaces for grouping individual users into logical groups or roles. Given a user name, the role provider system returns a list of roles to which the user belongs. The membership provider creates a user token from the logon name and password, while the role manager creates a set of group membership tokens for the current user.

The role manager is optional, so if a custom authentication system does not support groups (Windows Live ID, for example), then a role manager is not necessary. Windows SharePoint Services supports one membership provider and one role manager per URL zone (SPUrlZone). The ASP.NET forms roles have no inherent rights associated with them. Instead, Windows SharePoint Services assigns rights to the forms roles through its policies and authorization.

The log-on form (login.aspx) is provided by Windows SharePoint Services and resides in the _layouts virtual directory (in Local_Drive:\\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS). This file implements the ASP.NET Web form controls used to collect user credentials and cache credentials in a cookie.

The central administrator for a Web site must register the membership provider and role manager by modifying the web.config file for the run-time virtual server. If no providers are registered, ASP.NET forms-based authentication does not work. The central administrator must similarly update the sptimer.exe.config file.

Windows SharePoint Services consumes the standard ASP.NET 2.0 role provider interface to gather group information about the current user. For authentication purposes, roles and groups are the same thing: a way of grouping users into logical sets for authorization. Each ASP.NET role is treated as a domain group by Windows SharePoint Services.

For information about the pluggable authentication framework provided by ASP.NET, see New Security Features in ASP.NET 2.0.

Delegated Authentication

Windows SharePoint Services supports delegating end-user credentials from an external system to a SharePoint deployment, allowing trusted services to pass user identities for authorization when the end user does not connect directly to Windows SharePoint Services but connects through another system. Windows SharePoint Services thus allows trusted code to specify who the current user is without Windows SharePoint Services having that user’s credentials.

Through delegated authentication one server delegates an end-user's authentication to another server. The client computer makes a request to the first server, which in turn makes one or more requests to the second server on the part of the end user. To succeed, the first server must delegate the end-users authentication to the second server, which requires one of two trust relationships:

  • The client trusts the first server with its password, for example, to use basic authentication, or a server-side credential store such as the pluggable single sign-on mechanism of Microsoft Office SharePoint Server 2007 or Active Directory Federation Services (ADFS).

  • The second server trusts the first server to pass on valid credentials for valid purposes, for example, to establish a Kerberos-constrained delegation trust relationship between the servers.