这是一个建筑问题 - 我希望这是一个正确的堆栈交换 - 这似乎没有一个自然的家... ...
我工作的系统分布在数据中心 - DMZ中的Web服务器,然后在安全区域(通过防火墙)调用Web服务以访问数据。这当前使用WSE的asmx服务,在SOAP标头中传递用户名和密码凭据。这些是未加密的。视图一直是这提供了一些安全措施(互联网上的攻击者DMZ服务器无法访问从Intranet DMZ服务器访问的服务的凭据)。
我们希望转向使用WCF,但坚持使用Web服务。我们希望使用wsHttpBinding与其他客户端实现最佳互操作性并符合标准。继续使用用户名身份验证这似乎强制要求使用SSL或消息加密,这对于很多人来说似乎有点过分加密我们自己控制两个端点的数据中心内的连接。
我很想知道这是否是其他人做的以及我们有什么替代品。我考虑过(并排除了以下几点)
对于其他人如何在具有安全区域的数据中心中使用WCF的任何想法都将非常感激
答案 0 :(得分:3)
使用BasicHttpBinding - 我认为这可以配置为传递用户 使用TransportCredentialOnly未加密的凭据。然而, 有点担心BasicHttpBinding是作为遗产 方法,与其他技术的互操作性较小
基本HTTP身份验证是您可以使用的最具互操作性的内置身份验证机制,但它以纯文本格式发送密码。如果您在IIS中托管服务并且不想使用Windows帐户进行身份验证,那么使用也会有一些小问题。
SecurityMode =无 - 不使用任何凭据。我们的安全人员 因为外部网络服务器上的攻击者可能会对此感到不满意 获得他们喜欢的任何服务
确保企业环境中的服务是必须的。
更改为使用其他身份验证类型,例如视窗 凭证 - 担心这对我们的方式有很大的改变 目前运营这些服务以及我们是否可以访问 来自DMZ的目录服务器。
开始使用Windows凭据后,您必须为两个网络使用相同或受信任的域。
在这种情况下,更好的选择是证书(CertificateOverTransport
自定义安全模式)。 WCF中的基本身份验证和UserNameToken身份验证的问题是用户名和密码作为纯文本传输。这也是为什么默认情况下WCF(以及.NET 4之前总是)要求通过HTTPS或通过消息安全性进行加密的原因。任何攻击者(包括更危险的内部攻击者)都可以在DMZ或内部网络中嗅探通信,并获取访问您服务所需的所有凭据。
一旦开始使用证书,带有私钥的证书本身将安全地存储在DMZ中的服务器上 - 您甚至可以使证书不可导出。一旦DMZ应用程序调用您的内部服务,它将把有关使用过的证书的信息添加到SOAP标头中并签署消息的时间戳。任何人都可以验证签名(并证明调用者的身份),但只有私钥的持有者可以创建一个=即使攻击者获得网络通信访问权限,他也无法窃取身份。还有其他与证书相关的安全机制。
UserNameToken(在WSE中使用)支持加密密码,但WCF没有实现此功能。
要避免为UserNameOverTransport
或CertificateOverTransport
请求加密,您必须use custom binding(仅适用于.NET 4 - 之前版本需要MS中的某些KB)。