网站注册域名后怎么做,如何做求职招聘网站,深圳食品网站建设,官网做得好的公司众所周知#xff0c;WS-Security设定的目标之一是对SOAP消息强制执行完整性和/或保密。 在完整性的情况下#xff0c;添加到SOAP消息的签名是数学过程的结果#xff0c;该过程涉及发送者的私钥#xff0c;从而导致加密的消息摘要。 默认情况下#xff0c;大多数框架… 众所周知WS-Security设定的目标之一是对SOAP消息强制执行完整性和/或保密。 在完整性的情况下添加到SOAP消息的签名是数学过程的结果该过程涉及发送者的私钥从而导致加密的消息摘要。 默认情况下大多数框架例如WSS4J仅对正文进行签名。 如果要添加额外的标头例如Timestamp标头则需要明确指示对其进行签名。 使用WSS4J例如Spring的支持你可以设置包含本地元素名称的逗号分隔的列表并使用securementSignatureParts属性对应的命名空间。 在下面的示例中如何指示它对Body和Timestamp元素及其同级元素进行签名。 这将导致将两个数字签名附加到消息中 property namesecurementSignatureParts value{}{http://schemas.xmlsoap.org/soap/envelope/}Body;{}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp
/property 最终SOAP消息将与XML数字签名数据以及大多数情况下包含证书的BinarySecurityToken一起发送。 到目前为止没有新内容。 但是令我吃惊的是似乎没有广泛了解BST的目标是什么也不知道如何使用它来控制身份验证。 让我尝试阐明一下与SOAP消息一起发送的发件人的证书起着标识的作用。 您可以将其与用户名进行比较。 应该清楚的是消息中的证书不能被信任用户名也不能不经过密码验证。 到目前为止每个人都对此表示同意 “是的当然需要对证书进行验证才能被信任然后您便会被设置” 但这还不是全部。 证书的验证与身份验证不同。 消息中的证书有效并且由已知CA签名的事实不足以考虑发件人是否已通过身份验证。 例如在最恶意的时刻我本可以截取消息更改内容基于我的私钥创建新的签名并用我的证书替换消息中的BST。 我的证书完全可以是正式的CA签名证书甚至由您使用的同一CA签名因此它可以通过验证检查。 如果框架只是简单地验证消息中的证书那么我们将完全没有安全性。 注意如果您是通过安全传输发送邮件则可能是我无法截获该邮件。 但是安全传输大多在实际端点之前终止而使一小部分传输“不安全”。 尽管这部分将主要在公司内部进行但是我想指出的是无论您的传输多么安全端点都有责任验证发件人的身份。 例如; 在异步系统中SOAP消息可能已经放置在消息队列上以便稍后进行处理。 当由端点开始处理时安全传输的踪迹早已消失。 您必须使用消息中包含的信息来验证身份。 为了解决此漏洞我们有两个解决方案第一个解决方案进一步建立在我们已经描述的基础上消息中的证书根据信任库中的CA根证书进行了验证。 在这种情况下建议首先缩小可信CA的范围。 例如您可以在有限的CA列表中与客户达成协议以从中获取证书。 这样一来您已经降低了信任更多“灰色区域” CA的风险因为这些CA可能不遵循发出如此严格的证书的规则例如正确检查其客户的身份。 其次由于您的受信任CA发出的*每张*证书都将被视为“已认证”因此我们将通过发出一些额外的支票来弥补漏洞。 使用WSS4J可以基于证书的主题DN属性配置匹配模式。 他们对此有一个不错的博客条目 http : //coheigea.blogspot.ie/2012/08/subject-dn-certificate-constraint.html 。 我们可以指定证书的DN必须匹配给定值如下所示 Wss4jHandler handler ...
handler.setOption(WSHandlerConstants.SIG_SUBJECT_CERT_CONSTRAINTS, CN ...); 注意目前在Wss4jSecurityInterceptor中使用Spring对WSS4J的支持尚无此设置器因此您必须对其进行扩展才能启用此功能 总结正在执行的步骤 消息中包含的证书已根据您的受托机构中的受信任CA进行了验证。 验证成功后它将通知应用程序证书仍然有效并且实际上已由您认为可信的CA分发了该证书。 此检查为我们保证了证书确实属于证书声称属于的一方。 您也可以选择在吊销时检查证书以便我们不再继续信任被明确吊销的证书。 WSS4J将检查证书的某些属性是否与特定服务的所需值匹配主题DN证书约束支持。 这将是身份验证步骤 一旦发现证书有效我们将检查证书的所有者是否也是我们要授予访问权限的证书的所有者 最后通过创建消息的新摘要来验证消息中的签名将其与消息中的解密摘要进行比较依此类推。 请注意默认情况下不进行此检查至少在使用WSS4J时 如果您不指定它而只是将您的CA添加到信任库中您将留下一个安全漏洞 第二种解决方案不需要额外的配置并且仅取决于要在信任库中显示的发送者的证书。 消息中包含的证书与信任库中的证书匹配。 如果它们匹配则对发送者进行身份验证。 无需针对CA验证证书因为在信任库中导入的证书是显式可信的WSS4J仍将检查证书是否未过期并可能对其进行吊销检查。 同样信任库中没有CA证书或CA中间证书 也只有您要授予访问权限的发件人的证书。 因此通过从信任库中添加或删除其证书来控制访问。 这要求您在最初导入证书时要谨慎因为您必须确保它们实际上代表发送者。 但这是在将证书添加到信任库时以及在添加CA证书如第一个解决方案时始终必须执行的操作。 结论 假设您可以限制受信任的CA则在大多数情况下第一种解决方案是首选的也是最具扩展性的。 对于新客户端不需要对信任库进行任何更改。 匹配的属性可以存储在外部因此很容易更改/添加。 另外当客户端证书过期或被吊销时您无需执行任何特殊操作。 发件人将在给定时刻使用新证书并将根据您的信任库中的CA直接对其进行验证。 在第二种解决方案中您将必须将新证书添加到受托者中并将旧证书保留一段时间直到执行切换为止。 总体经验教训水密安全很难。 IT领域的1规则假设是所有麻烦的源头在这里确实是正确的。 持怀疑态度并确保您完全了解正在发生的事情。 在您确定默认设置之前请不要信任默认设置。 房子警报的默认设置例如123456也不是好主意。 Tomcat安装上的默认管理员密码也不是。 参考 WS-Security在Koen Serneels –技术博客博客中 使用BinarySecurityToken进行 JCG合作伙伴 Koen Serneels的身份验证 。 翻译自: https://www.javacodegeeks.com/2013/09/ws-security-using-binarysecuritytoken-for-authentication.html
