混合面向服务的架构安全性和业务逻辑
我有一个 SOA，它大量使用随机数（即一次性的安全令牌）。
我的应用程序从客户端获取一个随机数，对其进行验证，然后将一个新的随机数作为每个回复的一部分发送回所述客户端。每个回复中还包含在随机数经过身份验证后立即执行的业务逻辑操作的结果。
随机数验证和生成在操作上与业务逻辑耦合，因为两者都是响应每个客户端请求而发生的。但是我不希望两者在代码中耦合。根据 SOA 原则对它们进行分区的正确方法是什么？将安全性和业务逻辑分解为两个独立的服务，一个服务调用另一个服务作为每个客户端请求的回复的一部分，这样是否太过分了？
I have a SOA which makes heavy use of nonces (i.e, one-time one-use security tokens).
My app takes a nonce from a client, verifies it, then sends a new nonce back to said client as part of every reply. Also included in each reply are the results of business logic operations that executed right after the nonce was authenticated.
The nonce verification and generation are operationally coupled with the business logic, since both occur in response to every client request. However I don't want the two to be coupled in code. What's the right way to partition them in accordance with SOA principles? Is it too much to break the security and business logic into two separate services, with one calling the other as part of each reply to each client request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，将它们分开是有道理的。但我认为他们根本不应该互相了解（直接打电话给对方）。
我将深入探讨如何实现类似功能的具体示例和技术。
在 Web 框架 Struts2 中，所有传入请求在到达用户定义的对象（称为操作）之前都会经过一系列操作（称为拦截器）。然后该操作将访问业务层。
提交网络表单时存在重复提交的问题。因此，防止这种情况的一种方法是使用与表单提交一起发送的令牌。因此，我们需要创建一个唯一的令牌，将其作为隐藏字段，然后当我们收到请求时，仅在令牌良好的情况下才处理它。这可以防止用户做出类似不小心多次购买某物之类的事情。
在 Struts2 中有一个特殊的服务器端令牌标签，它为我们创建隐藏字段。因此，每个表单都需要做一些事情。令牌拦截器如果处于活动状态，将强制该值始终存在，并且在接收表单时有效，并且将重定向不存在于其他位置的响应。
实现随机数拦截器/过滤器来检查传入的随机数值是否良好以及为响应添加正确的随机数值到响应的想法应该完全独立于业务逻辑。
这里的例子是 html 表单，但添加一个拦截器（或者任何你所谓的“在请求/响应级别处理横切关注点的适当技术”），将这样的值添加到 json 或 xml 消息应该非常容易可能会产生最优雅的结果。
以下是 struts2 拦截器参考的链接（它可能会更好地阐明这个想法）：
http://struts.apache.org/2.2.1.1/docs/interceptors.html
下面两个链接都是管理token的拦截器：
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
我预计只有每个链接的前几段会有用，但类似的东西因为你的技术应该不错。
Yes it makes sense to separate them. But I don't think they should have awareness of each other at all (Call each other directly).
I'll dive into a specific example and technology of how something similar is implemented.
In the web frame work Struts2 all incoming requests pass through a stack of operations(called interceptors) before arriving at a user defined object (called an action). The action then will access the business tier.
When submitting a web form there is the issue of double submission. So one way to protect against this is with a token that is sent along with the form submission. So we need to create a unique token place it as a hidden field, and then when we receive the request only process it if the token is good. This prevent users from doing something like accidentally buying something more than once.
In Struts2 there is a special server side token tag which creates the hidden field for us. So there is something that needs to be done for each form. The token interceptor if active will enforce that this value always exists and is good when receiving the form and will redirect responses that do not somewhere else.
The idea of implementing a nonces interceptor/filter that checks that the incoming nonce value is good and for responses adds the correct nonces value to the response should be completely independent of the business logic.
The example here is with html forms but adding an interceptor(or whatever you call "that which handles cross cutting concerns at the request/response level" for your appropriate technology) which adds such a value to json or xml messages should be pretty easy and likely produce the most elegant result.
The following is a link to struts2 interceptor reference (it might clarify the idea better):
http://struts.apache.org/2.2.1.1/docs/interceptors.html
The following two links are both interceptors which manage tokens:
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
I expect only the first few paragraphs of each link will be useful but something like it for your technology should be nice.
我认为您上面概述的内容符合 SOA 原则。您将两组不同的操作分开 - 一旦服务具有业务逻辑，另一组就有安全逻辑。
如果您拥有（或可能拥有）其他依赖随机数的服务，则尤其如此。
I think what you outlined above would be in keeping with SOA principles. You're keeping two distinct sets of operations separated - once service has the business logic, the other has the security logic.
This would be especially true if you have (or the potential of having) other services that would rely on nonces.