这句话听起来很明显，但实际上并不总是考虑在内。 一些组织要么没有这样的集中式集成控制，要么因为“妨碍了一切”而停止使用它。 充其量，这意味着集成信息被保存在某些关键人物的头上，这很冒险。 通常，在这样的地方的团队不敢“在某些情况下仍然依赖它们”更新服务合同，而是在需要更新时随时复制它们，这与SOA相反。
有时，一个好主意只需要退后几步即可正确应用。 我在这篇文章中解释了为什么我认为对SOA路线图的需求应能激发大多数Web服务（包括非敏感服务）上存在安全访问限制。
为什么这么简单的想法很难付诸实践？
有几个因素可以促使团队跳过这一重要的文档编制步骤：
- 其他重要的短期任务的紧迫性，以及团队不断地“扑灭大火”的感觉，没有时间做其他事情
- 缺少明确标识的中央存储库，该存储库用于在何处访问和发布此类信息（例如SOA注册中心或存储库），或者缺乏对这些信息的使用。
- 缺乏集中式的管理，无法监督整合
从人为因素的角度来看，“我已经受够了”综合症会使这种情况恶化。 在复杂的多团队/多项目环境中，已经为眼前的问题所困扰的个人通常不会主动寻找其他项目难以解决（并解决）的依赖问题。 我们需要对此进行预测并积极帮助那些团队，同时要记住，他们要处理的其他问题当然也很重要。
以上内容的核心根源是，在可能的情况下，更容易跳过集成的验证/文档步骤。 我们必须通过宣传集中式集成信息的价值以及提高实现无证集成的难度来扭转这种感觉。
我们需要的
我们需要一个易于使用的过程来收集，验证和发布系统之间当前和将来的依赖关系。 一个关键方面是以“足够的治理”方式使它保持简单并与实际使用它的人保持联系。
四个主要组成部分似乎是：
- 一个清晰的过程，用于请求新的集成或更新现有的集成。 这包括从业务和技术角度进行验证，以确保环境保持尽可能清洁和面向未来。 如果执行了EA工作，那么大多数请求都来自EA团队或来自EA团队，这使得此步骤变得微不足道！ 在实践中，当项目团队在详细的设计或实施阶段确定所需的依赖关系时，也将来自项目团队。
- 一个明确标识且易于访问的存储库，可在其中查找当前和计划中的集成。 该存储库必须包括每个未来依赖项的版本控制以及弃用/停用计划。
- 负责更新中央存储库的团队，使路线图保持最新。 如果可以的话，通常是EA团队。
- 在技术层面上，如果不涉及上述三个组件，则无法执行集成。 这应避免在合同更新引发问题之前一直隐藏的“幻影依赖项”。
在实践中，第四个组件应是企业范围内的IT原则，该原则规定每个Web Service实现必须要求调用应用程序具有安全授权。 当服务需要时，这将不会阻止其他安全机制的存在，例如，传输带有发起原始业务操作的人工用户身份的票证（REST和SOAP都允许同时存在多个安全令牌）。
通常必须通过将技术文档和代码示例附加到IT原理上来简化该原理的实现。 因为我们不希望同事之间互相攻击，所以可以采取低风险的方法，其目的只是确保让EA团队更容易建立幻影依赖。 使用SOAP时，我的建议是使用简单的WS-UsernameToken策略，并为每个客户端应用程序关联一个用户名/密码对。 使用REST时，一种众所周知的机制是使用HMAC，将请求的一部分与随机数和/或到期日期一起进行哈希处理（此机制类似于Amazon S3所使用的机制）。
结论
在本文中，我试图解释为什么我认为在每个Web服务中系统地采用一个简单的安全策略有助于跟踪IT状况，并确保SOA治理团队看不到“幻影依赖项”。 此安全策略的实施必须简单易行，并得到帮助文档的支持，并且不能过于强大，仅足以确保EA团队了解所有集成实施。
参考：来自Svend博客的 JCG合作伙伴 Svend Vanderveken的Web服务安全性和SOA路线图的人为因素 。
翻译自: https://www.javacodegeeks.com/2012/09/web-service-security-and-human.html
