There are more reasons why you can receive this exception. The obvious one is that you use SPContext in the elevated block. For more info see this post . I will describe a less obvious reason in following article. The RunWithElevatedPrivileges method runs the code under the account of the application pool. In the productive environments has the application pool account only limited privileges. Generally the permissions are so defined that you can do anything you want in the current site however if you try to run e.g following code:
var webApp = SPWebApplication.Lookup(new Uri("http://localhost/sites"));
webApp.Sites.Add("http://localhost/sites/", "user", "email");
you will receive the access denied exception. So how to solve this problem:
- Define an account that has only the needed permissions to perform the desired operation. In this specific scenario, you can define a user that has self service site creation permissions and modify the code that it uses self service site creation.
- Run the code, that throws exception under the specified account. You can achieve this for example so, that you open the SPSite impersonated. See this.
Tags: Permissions, SharePoint
Vojtech Nadvornik's Blog 
March 8, 2012 at 4:08 pm |
I suspect I have a similar problem. I’m trying to verify whether or not a particular TargetApplication exists in the Secure Store (line numbers added for readability).
1. private void VerifySSOTargetApplication()
2. {
3. SPServiceContext context = SPServiceContext.GetContext(SPServiceApplicationProxyGroup.Default, SPSiteSubscriptionIdentifier.Default);
4. SecureStoreServiceProxy ssp = new SecureStoreServiceProxy();
5. ISecureStore iss = ssp.GetSecureStore(context);
6. try
7. {
8. TargetApplication targetApp = iss.GetApplication(SSO_TARGET_APP_ID); // SSO_TARGET_APP_ID is declared as a protected string in the class this method exists in
9. }
10. catch (SecureStoreServiceTargetApplicationNotFoundException ex)
11. {
12. // handle TargetApplication doesn’t exist here
13. }
14. }
Even when VerifySSOTargetApplication() is run with elevated privileges, line 8 throws an “Access Denied” error.
My suspicion is that the Secure Store Service has its own App Pool, with its own credentials, different from those of the main sharepoint farm and its app pool.
Any ideas how to work around this? As a developer, I have no access to the production server, and can not make changes to its configuration…