SOA服务设计/身份验证

Question

我对SOA还比较陌生，因此正在进行实验。

目前，给我带来最大问题的部分是身份验证，我目前的想法包括以下内容：

客户端向身份验证/用户服务发送某种身份验证消息，该服务查询数据库，如果找到用户且密码有效，则会响应会话ID，此ID将在此客户端的所有后续请求中使用。

这对我来说似乎相当不错，但我不知道该如何处理其他服务的请求，我想到了三种不同的方法。

1. 每个服务都询问身份验证服务会话是否有效，以及用户所在的角色。身份验证服务查看数据库并相应地回复。

2. 身份验证服务在RAM中保留所有会话信息，并在没有数据库往返的情况下响应请求。

3. 身份验证服务向ESB发送授权消息，ESB将此授权消息转发到每个服务，并缓存这些服务。不需要进一步向身份验证服务发出请求。如果用户注销或其角色更改，则会发送另一条消息并由所有服务处理。

我认为第一种方法会对身份验证服务/数据库造成太大的压力，但实现起来需要的工作最少。

第二种方法仍然非常容易实现，但对身份验证服务的压力几乎没有改变。

第三种方法的实现稍微复杂一些，但响应时间缩短，因为不需要向身份验证服务发起请求。虽然，如果有太多会话信息，这种方法将失败，并且可扩展性几乎不存在。

- user158761

Answer 1

如果所有服务都是内部的，最好的方法应该是这样的：

1. 认证服务向服务客户端发出令牌。
2. 服务客户端将令牌包含在SOA消息中，使用WS-Security或类似的方式进行封装。
3. 在提供服务之前，服务应该通过认证服务验证令牌。

对于外部服务，我建议您查看像SAML这样的联合解决方案。

- ZZ Coder

---

请问您能回答一下这个问题吗？http://stackoverflow.com/questions/9553267/soa-design-parameter-decision - LCJ

Answer 2

不要过早优化。 你承认更复杂的选项3是不必要的。如果您能够快速实现，选择选项2。稍后可以进行性能测试并更改，但我敢打赌，选择选项2时您不会有“瓶颈”问题。

- Alex

---

你能回答一下 http://stackoverflow.com/questions/9553267/soa-design-parameter-decision 吗？ - LCJ