IIS 上托管的 WCF 服务和 IIS 上的客户端网站
以下是所需的设置：
- wsHttpBinding 服务位于防火墙后面的机器 1 上的 IIS 6 上。
- 客户端是 DMZ 上机器 2 上 IIS 6 上的前端网站。
目前，我们可以使用 Windows 身份验证对客户端进行身份验证，但需要进行模拟，
<identity impersonate="true" userName="OurCompany\Me" password="Blahblahblah" />
因为网站将使用“ASPNET”作为用户名，而该用户名不在域中。
由于安全问题，我们现在想放弃这种方法；我们不想在 DMZ 上公开此类信息。
有什么方法可以在不使用的情况下正确进行身份验证 冒充客户端 配置？
如果我们改变以便我们使用 证书认证可以吗 影响服务运营 需要模拟（需要 模拟文件访问 例如网络）？
谢谢。
Here's the desired setup:
- Service with wsHttpBinding is on IIS 6 on Machine 1 behind the firewall.
- Client is front end website on IIS 6 on Machine 2 on a DMZ.
We are currently able to authenticate the client using Windows authentication, but with impersonation
<identity impersonate="true" userName="OurCompany\Me" password="Blahblahblah" />
since the website would use the "ASPNET" as username, which is not in the domain.
We now want to move away from this method, because of safety issue; we don't want to expose this kind of info on the DMZ.
Is there any way to get authenticated properly without using
the impersonate on the client
config?If we changed so that we use
certificate authentication, would it
affect service operations that
require impersonations (needed
impersonations for file access on
the network for example)?
thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
现在这个问题已经解决了，我认为分享解决方案是有建设性的。
就我最初的问题而言 - 是否能够在不在配置或前端代码中显式设置的情况下进行模拟。如上所述，应用程序池方法确实有效，但前提是客户端和服务器都位于同一域中。
由于位于 DMZ 中的网站客户端根本无法访问本地网络，这意味着我们无法模拟任何网络用户（这是我原来问题中的一个缺陷，说模拟有效 - 实际上不起作用） 。
所以唯一的办法就是使用证书。由于这是内部通信，因此我使用 makecert 在每个服务器/客户端上生成了一个测试证书。使用对等信任证书身份验证，我能够在客户端和服务器之间进行通信。这将确保 DMZ 区域中不显示任何 Windows/网络用户帐户信息。
This has been resolved now, and I think it'd be constructive to share the solutions.
In terms of my original question - whether it's able to do impersonation without setting it explicitly in the config or in the front end code. As mentioned by the above, the App Pool method does work, but only when both the client and server are on the same domain.
Since the web site client being situated in the DMZ has no access of the local network at all, meaning we are unable to impersonate any network user (this is a flaw in my original question, saying the impersonation works - it was actually not working).
So the only way to go was using certificate. Since this is internal communications, I have generated a test certificate on each of the server / client sides with the makecert. Using peer trust certificate authentications, I am able to get the communication working between the client and the server. This will ensure that no Windows / network user account information is presented in the DMZ zone.