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

There is a common issue called Double Hope issue in IIS that troubles most Sharepoint / Asp.net 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.

Problem

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: http://msdn.microsoft.com/en-us/library/ms817871

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.

<machineKey  
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7
               AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"           
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>

Read more about it in 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 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
appPoolContext.Undo();
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"
 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 ");