Authentication of the Requests from the End-User Client

A typical scenario for authentication of the requests from the end-user client occurs when a user is logged in using an Active Directory domain user account that allows the user to access a network resource such as a Windows SharePoint Services site. When the user makes a page request to Windows SharePoint Services, IIS handles the request and authenticates the user. IIS could choose one of the three methods: Integrated Windows authentication, basic authentication scheme, or anonymous authentication.

Once IIS has authenticated the user, IIS impersonates that user account for the thread handling the request. At this point, control is handed over to the Windows SharePoint Services code to fulfill the request from the end-user client. The request contains the unique address of a resource in Windows SharePoint Services (a page, a document, a list item, and so on), and its associated ACL. The ACL specifies which security principal has what permissions on this object. It is possible that the object inherits its permissions from an object higher in the container hierarchy (for example, see the figure in section 2.1.2).

In addition to the resource's address, the request contains the action that has to be performed on the object, such as Read, Write, Delete, Check-out, and so on. The Windows SharePoint Services authorization system performs the following steps to determine whether the requestor can perform the requested action on the request object.

  1. When making the determination, the authorization function inspects the user's token (a data structure provided by Active Directory on the thread by IIS) containing the user and security group identifier. It compares this against the list of referenced SIDs in the site collection. As a performance optimization, once this comparison is made, only the SIDs in the user's token that are referenced in the site collection are used.

  2. The authorization code then uses the truncated user token and compares it against each access control entry (ACE) in the requested object's ACL. An ACE contains the security principal and the action(s) which the principal can perform on that object. By matching all of the principals in the ACEs against the user's token, the list of actions that the user can perform on the requested object is determined.

  3. The final step is to compare the requested action against the list of actions that the user can perform as determined by the authorization algorithm. If the requested action is present in the list of authorized actions for the user, the request is allowed; otherwise, the request is denied.