SharePoint security remain a confusing concept to most developers, and customizing SharePoint without a full grasp of the security model – impersonation, elevated security, AD authentication, FBA authentication – may have an un-intended security implication. This confusion is further compounded because SharePoint security is built as a layer on top of the existing ASP.NET authentication provider. Thus, SharePoint handles authorization and access control by verifying external security principals against securable SharePoint objects such as documents, document libraries, and other types of lists.
To further ensure that user’s security in one site collection does not affect the settings in another, SharePoint treats each site collection as an island. Understanding SharePoint internal security workings is very important when you call runWithElevatedPrivilege delegate in your code. This understanding is critical to knowing which account is used to either an internal securable object, or external resources. So, let’s dig into details of the internal workings of SharePoint.
Authenticated User and Identity of current thread: For a normal process, the identity of the current thread is the identity of the current user. Interestingly enough, there are two identities at play. The first is the windows identity, and the second one is the WSS identity. That these identities are same until you need to run in an elevated privilege mode is the cause of most confusion for developers.
Authenticated User and RunWithElevatedPrivilege Delegate: Before calling RunWithElevatedPrivilege delegate in your code, the SharePoint (WSS) and Windows Identities of an authenticated user are the same. After you call RunWithElevatedPrivilege delegate, two things happen:
The windows identity changes and impersonates the application pool account
- The SharePoint (WSS) identity changes and impersonates SharePoint system account (SharePoint\System) – this is an internal SharePoint account with a pervasive privilege to access and manipulate all security objects in SharePoint environment.
So, it is important to understand that you have total control and permission on any object within SharePoint when you call this delegate. You should also understand that you are impersonating the account of the application pool if you need to access resources external to SharePoint environment.
Shared Proxy Objects: From the discussion above, it is important to note that your identity is established when you create a shared proxy object. Compare the following two scenarios below
Scenario 1: You create your shared proxy object, then call RunWithElevatedPrivilege delegate.
Scenario 2: You call RunWithElevatedPrivilege, and then create your shared SharedProxy Object.
There is a common confusion around these two scenarios. In the first scenario, you notice that your thread still does not have access to the SharePoint securable objects and that you are unable to manipulate these objects even when you assumed you are running in elevated privilege mode; when you check thread identity, you notice that it is running under the Identity of the authenticated user. For the second scenario, however, things worked as expected, i.e., your code is able to manipulate SharePoint securable object. The identity of a shared proxy objects such as SPSite is established when you create an instance of that object. So, you if get current context, then try to run with elevated privilege, you are inadvertently running in the context of the authenticated user instead of the system account. You only run in the context of SharePoint\System account if you first call enter elevated privilege mode before you create the shared proxy object.
Web Part: How do all these affect web part deployed on SharePoint? Well, Web Parts or other custom applications does not execute under the worker process identity (application pool identity). Two things happens when a web part runs within the context of a SharePoint Portal – for a user authenticated against active directory, WSS switches the thread context to the windows identity, and for a user who is not authenticated against active directory, WSS switches the security to that of the machine account, which by default is IUSR_MachineName. The second scenario is what happens when your users are not authenticated against active directory, for example, when you use Form Based Authentication. You can configure the impersonation of IUSR_MachineName in the Web.Config file.
These subtle differences are very critical to your developing a secured SharePoint solution, and even more critical if you have multiple authentication providers in your environment.
** About the Author: Anthony Odole is a Senior Solution Architect with IBM Global Services. He is a SharePoint Subject Matter Expert. You can reach him at Odolea@gmail.com