Reader Level:

Double Hope Issue in Sharepoint/ application with IIS

By Shyju on Jan 09, 2011
There is a common issue called Double Hope issue in IIS that troubles most Sharepoint / applications that consume the resource in other servers.

There is a common issue called Double Hope issue in IIS that troubles most Sharepoint / applications that consume the resource in other servers. In application development most of the ones that talk to a different application resides in multiple servers.


This issue occurs when you try to access the resource outside server with current logged in user credentials. In this scenario, at first hope occurs when the user accesses the page from a client browser during authentication of the user with his own windows credentials. The second hope occurs when IIS tries to access the other server with the current user credential. In SharePoint world most of the application uses windows authentication to authenticate the user and impersonation is also set to true. Our application needs to talk to another application; let's say for example a webservice in another physical server or a sharepoint service in another Farm. In this scenario during the second hope IIS will pass the credentials with hashed password, so the other server cannot understand the credentilals.

You could also read more about this issue in MSDN:

How to solve the issue

Approach 1 : Use Same Encryption and Decryption

Use the same encryption and decryption key in web.config of both servers. This way we force the servers to use the same key.


Read more about it in

Approach 2 : Use IIS Application Pool Identity User

In this approach we need to use the application pool identity user for communication with another server. Here we change impersonation context application pool identity user when we communicate with the other applications. After consumption by another application we will revert back to the current user.

WindowsImpersonationContext  appPoolContext = null;
//Imperosonate application pool UserIdentity
  appPoolContext  = WindowsIdentity.Impersonate(System.IntPtr.Zero);
//Call all the web services here
//After the execution revert back to current user
Approach 3 : Communicate with a specific user credential

Another approach is to communicate with a specific domain user credential. In this approach we will be setting the credential explicitly to a specific domain user by passing user name and password. In this approach you could keep

//Create the service client
MyWebServiceclient = new MyvewebserviceViews(weburl + "/_vti_bin/views.asmx");
 //Set the credential of a domain user
MyWebServiceclient.Credentials = new System.Net.NetworkCredential("MyUser", "Password", "domain");
//Call the service
MyWebServiceclient.GetView(listname, viewName);

You could keep the user information in web.config and encrypt it.

1. Creat web.config entry

<section name="UserInfoSection"

UserInfoSection  username="value1" password="value2" domain="value3"/>

2. Encrypt the section

Go to Visual Studio command prompt and run

aspnet_regiis -pef  

3. Read the value from code

MyUserData = (System.Collections.IDictionary)
UserInfoSection ");