SharePoint user identity is sometimes confusing for developers….
- When connecting to external resources (like a SQL database via BDC) what user identity does SharePoint use?
- How does SharePoint impersonate when using forms-based authentication?
- What’s the difference between a Windows user and a WSS User?
- What is SPSecurity.RunWithElevatedPrivileges?
It’s questions like those above the can often lead to confusion – throw IIS authentication settings into the mix and developers too often find themselves scratching their heads as to why BDC (Business Data Catalog) or external resource access is not working.
My attempt at explaining impersonation within SharePoint is best summarized with the following table:
|Authentication||Windows Account||WSS Account|
|Elevated FBA||App Pool User||SHAREPOINTSystem|
|Windows||Windows User||Windows User|
|Elevated Windows||App Pool User||SHAREPOINTSystem|
SharePoint keeps track of two different user account types – Windows account identity, and internal WSS account. SharePoint uses the WSS account to grant access to secured SharePoint objects – lists, documents etc. The ASP.NET runtime, which SharePoint sits atop, impersonates the Windows account identity when executing a SharePoint web application, and it is this impersonation that dictates whether web parts or custom code logic is able to access external secured resources (files, SQL server etc).
Taking a closer look at the web.config for a virgin SharePoint site shows the following XML node:
The above node allows the ASP.NET runtime to impersonate the windows account passed by IIS (setting this to false restricts ASP.NET to run under the default worker process – typically the ASPNET local account).
Windows Authentication – SharePoint is configured by default to use Windows authentication (NTLM or Kerberos). When the user attempts to access a secured page within SharePoint an HTTP 401 status code is passed back through IIS, which then causes the familiar Windows credentials prompt to appear in the browser. After passing successful credentials; IIS authenticates the user and passes the windows user token on to SharePoint. The SharePoint web site executes within this new authenticated user context. In this authentication scheme the WSS account and windows identity account are synonymous – line 3 in the table above.
Forms Based Authentication – FBA is a completely different animal to Windows Authentication and is managed by ASP.NET rather than IIS. By default IIS passes the standard IUSER_MACHINENAME local user account token to ASP.NET. ASP.NET is configured to authenticate using forms by the following XML in the web.config file:
When ASP.NET detects FBA and a secured pages is requested by a user; the runtime looks for a known cookie, if the cookie is present the authentication succeeds, otherwise ASP.NET redirects the user to a login page. Upon successful authentication the SharePoint web application runs under the IUSER_MACHINENAME user context. The WSS account is depicted by the forms authentication identity, which is dependent on the membership provider configured in ASP.NET. Example WSS account identities under FBA are SQL member accounts via the Local SQL Membership Provider or AD members accounts via the AD Membership Provider.
Note: Authenticating against Active Directory using the AD forms-based membership provider is NOT the same as authenticating via Windows NTLM or Kerberos – in the former case the user context is still IUSR_MACHINENAME, where as Windows authentication receives the user token for the authenticated user from IIS.
Anyone who has played with SharePoint object model has probably used the SPSecurity.RunWithElevatedPrivileges function. This function allows access to secured SharePoint objects from the object model by changing the WSS user account context to SHAREPOINTSystem – a highly privileged user in SharePoint. Calling this function also has the effect of changing the current windows user context to the current application pool user, configured in IIS. In typical SharePoint farm installations, the application pool user is an AD user with restricted permissions and limited access to external resources, although typically this user has more permissions than the local IUSR_MACHINENAME user.
If you’re not concerned with FBA and/or anonymous access to your SharePoint sites then the anonymous account used by IIS is of no concern to you. All you need to remember is that the elevated privilege method switches the current authenticated windows user to the app pool user, which is probably desirable if the app pool user is configured for external resources via BDC. Most developers use this method to gain them access to secured SharePoint objects, but it is just as useful if you need access to external resources.
When setting up FBA with anonymous authentication scenarios it is important to be aware of the IUSR_MACHINENAME windows account in context. For example, if you reference custom ASCX files in SharePoint page templates and these ASCX user controls live in a secured directory on the server; then you’re going to see request for credentials on your anonymous site. If you have a web part that needs to access a third party system or network resource then the IUSR_MACHINENAME account will prevent your web part from working. Generally I suggest the use of SPSecurity.RunWithElevatedPrivileges function when accessing network/external resources. However, if you want to avoid a potential security hole because your code can now access any SharePoint object via SHAREPOINTSystem, then an alternative is to configure the IIS anonymous account as an AD domain account.
Hopefully this blog post has distilled the common confusion surrounding SharePoint identity, I know that I’ll be coming back to the above table from time to time.