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.ProblemThis 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 issueApproach 1 : Use Same Encryption and DecryptionUse 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 UserIn 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 userappPoolContext.Undo(); Approach 3 : Communicate with a specific user credentialAnother 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 clientMyWebServiceclient = new MyvewebserviceViews(weburl + "/_vti_bin/views.asmx"); //Set the credential of a domain userMyWebServiceclient.Credentials = new System.Net.NetworkCredential("MyUser", "Password", "domain");//Call the serviceMyWebServiceclient.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 sectionGo to Visual Studio command prompt and runaspnet_regiis -pef UserInfoSection 3. Read the value from codeMyUserData = (System.Collections.IDictionary)System.Configuration.ConfigurationSettings.GetConfig("UserInfoSection ");
C# Corner. All contents are copyright of their authors.