MSDN Magazine - February 2008 - (Page 57) tempts to access external objects outside of WSS, such as files maintained by the Windows operating system, the OS runs access checks using the Windows identity under which the code is currently executing. There are times when you need your code to execute with greater permissions than is possessed by the current user. For example, imagine a scenario in which your code must write data to a list when processing a request for a user that has nothing more than read-only permissions. By default your code runs with the same permissions as the current user. However, you can make a call to the RunWithElevatedPrivileges method of the SPSecurity class to elevate the security context of your code. Note that a call to RunWithElevatedPrivileges elevates both the WSS user identity and the Windows identity. Now imagine a scenario where a user has authenticated against a Windows account with a login of LITWAREINC\BrianC. A call to RunWithElevatedPrivileges will elevate the WSS user identity to the SHAREPOINT\System account. The SHAREPOINT\System account is built into the WSS runtime and is all powerful within the WSS authorization model. A call to RunWithElevatedPrivileges will also switch the Windows identity of the executing code so it runs under the worker process identity of the current Web Application: // BEFORE ELEVATION // WSS User identity = LITWAREINC\BrianC // Windows identity = LITWAREINC\BrianC SPSecurity.RunWithElevatedPrivileges(delegate() { // AFTER ELEVATION // WSS User identity = SHAREPOINT\System // Windows identity = LITWAREINC\SP_WorkerProcess }); In some scenarios, you might choose to call the RunWithElevatedPrivileges method to change the Windows identity of the current call before you attempt to access a file inside the Windows file system or a SQL Server database. Also note that switching the Windows identity over to a process identity such as LITWAREINC\ SP_WorkerProcess can eliminate the need to configure delegation within an Active Directory environment. This can be very valuable if you have custom Web Parts that access data in a remote SQL Server database using Windows integrated authentication. And then there are other scenarios where you might want to call the RunWithElevatedPrivileges method to elevate the WSS user identity to SHAREPOINT\System so that your code can perform operations not allowed by the current user. Once your code is running as SHAREPOINT\System, you can do pretty much anything you want within the WSS authorization subsystem. There is one tricky aspect of calling RunWithElevatedPrivileges to elevate to the SHAREPOINT\System account. For example, imagine you call RunWithElevatedPrivileges and then you attempt to access objects in the current site collection or site through the SPContext.Current property. You probably wouldn’t expect your code to fail, but it might: SPSecurity.RunWithElevatedPrivileges(delegate() { SPSite siteCollection = SPContext.Current.Site; // next line fails if current user is Contributor string siteCollectionOwner = siteCollection.Owner; }); Office Space february2008 57 http://xceed.com http://xceed.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.