我有一个大量使用nonce的SOA（即一次性一次性安全令牌）。
我的应用程序从客户端获取一个nonce，验证它，然后在每个回复中将新的nonce发送回所述客户端。每个回复中还包括在对随机数进行身份验证后立即执行的业务逻辑操作的结果。
随机数验证和生成在操作上与业务逻辑耦合，因为两者都响应于每个客户端请求而发生。但是我不希望这两者在代码中耦合。根据SOA原则对它们进行分区的正确方法是什么？将安全性和业务逻辑分解为两个单独的服务是否太过分了，一个服务调用另一个作为每个客户端请求的每个回复的一部分？
答案 0 :(得分：1)
是的，将它们分开是有意义的。但我认为他们根本不应该相互了解（直接互相打电话）。
我将深入探讨如何实现类似内容的具体示例和技术。
在Web框架工作Struts2中，所有传入请求都会在到达用户定义的对象（称为操作）之前通过一堆操作（称为拦截器）。然后，该操作将访问业务层。
提交网络表单时，存在双重提交问题。因此，防止这种情况的一种方法是使用与表单提交一起发送的令牌。因此，我们需要创建一个唯一的令牌，将其作为隐藏字段放置，然后当我们收到请求时，只有在令牌好的情况下才处理它。这可以防止用户做出多次意外购买的事情。
在Struts2中有一个特殊的服务器端令牌标记，它为我们创建隐藏字段。因此，每种形式都需要做一些事情。令牌拦截器（如果处于活动状态）将强制执行此值始终存在并且在接收表单时很好并且将重定向不在其他位置的响应。
实现检查传入的nonce值是否良好的nonce拦截器/过滤器以及响应的正确nonce值添加到响应的想法应完全独立于业务逻辑。
此处的示例是使用html表单，但添加了一个拦截器（或任何你称之为“处理请求/响应级别的交叉问题”的适当技术），它将这样的值添加到json或xml消息应该是很容易，很可能产生最优雅的结果。
以下是struts2拦截器引用的链接（它可能更好地阐明了这个想法）： http://struts.apache.org/2.2.1.1/docs/interceptors.html
以下两个链接都是管理令牌的拦截器： http://struts.apache.org/2.2.1.1/docs/token-interceptor.html
http://struts.apache.org/2.2.1.1/docs/token-session-interceptor.html
我希望每个链接的前几段都有用，但是对于你的技术来说应该很好。
答案 1 :(得分：0)
我认为您在上面概述的内容将符合SOA原则。您将两组不同的操作分开 - 一旦服务具有业务逻辑，另一组具有安全逻辑。
如果您拥有（或可能拥有）依赖于nonce的其他服务，情况尤其如此。