避免客户端双跳的解决方案>网络服务> SQL服务器
我的项目涉及用户从客户端连接到 Web 服务，然后将 Web 服务连接到 SQL Server。 Web 服务和 SQL Server 位于不同的计算机上。由于安全需求，我们在SQL Server中不能使用混合模式，只能使用Windows身份验证。
我们遇到了 Web 服务和 SQL Server 之间的“双跳”问题。我们正在使用 NTLM 身份验证，并且由于开销和学习曲线的原因，不想配置 Kerberos。我们也不希望 Web 服务和 SQL Server 在同一台计算机上。
据我了解，我们所有的要求都使得这种情况无法解决。然而，一位开发人员提出了这样的建议：
1）在 SSL 加密下将 Windows 用户名和密码从客户端发送到 Web 服务
身份验证的安全令牌
2）以某种方式将 Windows 用户名和密码转换为可以由 SQL Server进行 打个比方，听起来我们在连接到 SQL Server 时会在 C# 代码中执行 RUNAS。 Web 服务不会进行身份验证，只能通过 SQL Server 进行身份验证。
我的问题：
1）建议的解决方案可行吗？
2）如果是的话，会怎样做？
3）有任何网络资源可以帮助我了解如何做到这一点吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，这是不可能的。客户端进程无法访问用户密码，因此无法将其发送到 Web 服务层。客户端必须明确询问用户其密码。 如果客户端进程有密码并且愿意将其发送到 Web 服务，那么理论上，Web 服务可以为该用户/密码创建一个令牌（使用 LogonUser），然后使用该令牌连接到 SQL Server。这个所谓的解决方案充满了不值得讨论的多个安全问题。如果您的团队坚持这样做，请创建一个网络服务来执行此操作，要求团队成员连接到它，一旦您掌握了他的凭据（他将向您的服务发送他的密码，还记得吗？ ）连接到交换服务器并向首席执行官发送一封邮件，其中包含文本“解雇我，我是个白痴”。或者更改他在HR的直接存款银行和账户。发挥你的想象力......我希望现在你能更清楚为什么沿着你建议的道路走下去是一个非常糟糕的主意。
只需使用 Kerberos。
顺便说一句，如果您由于政府监管而需要对后端进行身份验证，请记住身份验证和审核始终带有“不可否认性” ' 的要求，并将密码发送到 Web 服务，以便它对您进行身份验证，这明显违背了该要求，因为 Web 服务可以伪装成用户执行任何它想要的操作。这就是 Kerberos 委派是约束委派。
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.
这是不可能的。想想看，如果应用程序能够简单地以这种方式生成安全令牌，那会有什么好处呢？您需要 Kerberos 来解决这个问题。
编辑：同样，runas 类比不适用于客户端尝试连续验证两个系统的情况，因为 runas 仅需要单跳，即使您切换用户也是如此。
This couldn't be done. Think about it, if applications could simply generate security tokens in this manner, what good would it be? You'll need Kerberos to overcome this issue.
Edit: Also the runas analogy doesn't apply in the case of a client attempting to authenticate into two systems successively, since runas only requires a single hop, even when you switch the user.