Voila! This would be some thing I would have hard time to make one understand. This topic is simple until one keeps it flat, else a complete confusing serious session.
This post would be my attempt to make it very easy for beginners to understand it very easily to basic of Identity.
Well, lets understand the simple terms.
1. Authentication
a. FBA
b. Windows
2. Windows Account
a. IUSR_MachineName
b. App Pool User
c. Windows User
3. WSS Account
a. FBA User
b. Windows User
c. SHAREPOINT \ System
Now, I hope the following lines are not new for you...
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>
which means ASP.NET runtime impersonates the Windows Account passed by IIS. SharePoint keeps track of both Windows Account as well as WSS account. It uses the WSS Account to grant access to secure SPObjects (name it). However ASP.NET which is the base, impersonates the Windows Account when running Sharepoint Application and decides if the resources (webparts, custom etc) can access other resources (files, SQLServer etc).
During Windows Authentication, when user passes right credentials - IIS passes the windows user token to SharePoint. And SharePoint uses 'this context' and executes under this user context. Meaning at this point both WSS Account and Windows Account use same user.
On the other hand FBA 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:
<configuration>
<system.web>
<authentication mode="Forms"/>
</system.web>
</configuration>
On successful authentication, SharePoint 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.
Now, when you run the context under RunWithElevatedPrivileges - function allows access to secured SharePoint objects from the object model by changing the WSS user account context to SHAREPOINT\System. The current windows user context now changes 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.
One problem with RunWithElevatedPrivileges is that, you now become System User and have access to 'EVERYTHING' - a security hole. So use caution while using it.
This post would be my attempt to make it very easy for beginners to understand it very easily to basic of Identity.
Well, lets understand the simple terms.
1. Authentication
a. FBA
b. Windows
2. Windows Account
a. IUSR_MachineName
b. App Pool User
c. Windows User
3. WSS Account
a. FBA User
b. Windows User
c. SHAREPOINT \ System
Now, I hope the following lines are not new for you...
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>
which means ASP.NET runtime impersonates the Windows Account passed by IIS. SharePoint keeps track of both Windows Account as well as WSS account. It uses the WSS Account to grant access to secure SPObjects (name it). However ASP.NET which is the base, impersonates the Windows Account when running Sharepoint Application and decides if the resources (webparts, custom etc) can access other resources (files, SQLServer etc).
During Windows Authentication, when user passes right credentials - IIS passes the windows user token to SharePoint. And SharePoint uses 'this context' and executes under this user context. Meaning at this point both WSS Account and Windows Account use same user.
On the other hand FBA 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:
<configuration>
<system.web>
<authentication mode="Forms"/>
</system.web>
</configuration>
On successful authentication, SharePoint 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.
Now, when you run the context under RunWithElevatedPrivileges - function allows access to secured SharePoint objects from the object model by changing the WSS user account context to SHAREPOINT\System. The current windows user context now changes 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.
One problem with RunWithElevatedPrivileges is that, you now become System User and have access to 'EVERYTHING' - a security hole. So use caution while using it.
Comments