My project invoves a user connecting from client to web service, and then web service to SQL Server. The web services and SQL Server are on separate machines. Because of security requirements, we cannot used mixed mode in SQL Server, only Windows authentication.
We are experiencing the “double-hop” issue between web service and SQL Server. We are using NTLM authentication and do not want to configure Kerberos because of the overhead and learning curve. We also don’t want to have the web service and SQL Server on the same machine.
From what I understand, all of our requirements make this scenario impossible to resolve. However, a developer came up with this suggestion:
1) Send the windows username and password from the client to the web service under SSL encryption
2) Somehow convert the windows username and password into a security token that could be authenticated by SQL Server
To make an analogy, it sounds like we would be doing a RUNAS in the C# code when connecting to SQL Server. There would be no authentication for the web service, only through SQL Server.
My questions:
1) Is the proposed solution possible?
2) If so, how would it be done?
3) Any web resources to help me understand how it could be done?
No, this is not possible. The client process does not have access to the user password, and hence it cannot send it to the web service tier. The client would have to explicitly ask the user for its password. If the client process has the password and is willing to send it to the web service then, in theory, the WebService can create a token for that user/password (using LogonUser) and then connect to the SQL Server using that token. This so called solution is so riddled with multiple security problems that is not worth discussing. If your team insist on it, make a web service that does that, ask a team member to connect to it, and once you got hold of his credentials (he will send your service his password, remember?) connect to the exchange server and send a mail to the CEO with the text ‘Fire me, I’m an Idiot’. Or change his direct deposit bank and account in HR. Use your imagination… I hope now is a bit clearer why going down the path you propose is a very bad idea.
Just use Kerberos.
BTW, if you need to authenticate to the back end due to government regulation, then bear in mind that authentication and audit always come with a ‘non-repudiation’ requirement, and sending the password to the web-service so it authenticates on your blatantly contradicts that requirement, since the web-service can do any operation it wants masquerading as the user. This is what Kerberos delegation is constrained delegation.