Double Hope Issue in Sharepoint/Asp.net application with IIS

This is a common issue called Double Hope issue in IIS and troubles most Sharepoint / Asp.net application which consume the resource in other servers .In application development most of the one talks to different application resides in multiple servers.

Problem
This issue occurs when you try to access the resource outside server with current logged in user credentials. In this scenario first hope occurs when user access the page from client browser that time its authenticate the user with his own windows credentials. The second hope occurs when IIS try 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 also set to true. Our application want talk to other application.Let 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 credentilal.


You could also read more about this issue in msdn http://msdn.microsoft.com/en-us/library/ms817871
How to solve the issue
Approach 1 : Use Same Encryption and Decryption
Use same encryption and decryption key in web.config of both servers. This way we could force the servers to use the same key.
< machineKey
validationKey ="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7
AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"
decryptionKey ="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation ="SHA1"
decryption ="AES"
/>
Read more about it http://msdn.microsoft.com/en-us/library/ff649308.aspx





Approach 2 : Use IIS Application Pool Identity User
In this approach we need to use the application pool identity user for communication with other server. Here we change impersonation context application pool identity user when we communicate with the other applications.After the consumption of other 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
appPoolContext.Undo();

Approach 3 : Communicate with specific user credential
Another approach you could communicate with 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"
type ="System.Configuration.SingleTagSectionHandler"/>

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

2. Encrypt the section
Go to visual studio command prompt and run
aspnet_regiis –pef UserInfoSection

3. Read the value from code

MyUserData = (System.Collections.IDictionary)
System.Configuration.ConfigurationSettings.GetConfig(" UserInfoSection ");