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 ");