负载均衡情况下的 OpenID
我正在考虑使用 Java + Tomcat/JBoss 实现 OpenID 提供程序（'OP'）。
现在，OpenID 的关键之一是
- 用户与 OP 和 RP 进行通信，并与两个站点进行会话。
- OP 和 RP 相互通信以确保用户没有伪造任何内容。
我无法找到任何文档的一个主题是如何在负载平衡情况下正确实现这一点的问题。
我担心的一般问题是 RP 连接到 OP 并最终位于与用户不同的应用程序服务器上。
我的问题：
- 处理这个问题的正确方法是什么？
- 什么是“最好的”OpenID 库 使用？
谢谢。
I'm looking at implementing an OpenID provider ('OP') using Java + Tomcat/JBoss.
Now one of the key things about OpenID is that
- The user communicates with both the OP and the RP and has a session with both sites.
- The OP and RP communicate with each other to ensure the user hasn't faked anything.
A subject I've not been able to find any documentation on is the question on how to correctly implement this in a load balanced situation.
The generic issue I fear is that the RP connects to the OP and ends up on a different application server than the user.
My questions:
- What is the right way to handle this?
- What is the 'best' OpenID library to
use?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将对话状态保存在共享存储中。 即数据库或分布式缓存。 缓存会更快，而且你也不需要太多的持久性。
使用粘性会话进行负载平衡（来自同一客户端的所有后续请求都到达同一服务器）将减少缓存更新的数量。
（我最初打算建议的集群 HTTP 会话不起作用，因为相同的对话分布在两个会话：用户会话和应用程序会话之间。）
Save the conversation state in a shared storage. That is, database or distributed cache. Cache would be faster, and you don't need much of persistence anyway.
Load-balancing with sticky sessions (all consequent request from the same client come to the same server) would reduce the number of cache updates.
(Clustered HTTP sessions that I intended to advice initially wouldn't work as the same conversation is spread between two sessions: user's and application's.)
在 OP 方面，真正需要在集群中的计算机之间共享的唯一特定于 OpenID 的状态是关联（共享密钥及其句柄）。 这是相当可缓存的； 给定关联句柄的秘密永远不会改变，它们具有明确定义的生命周期，并且不应该有那么多。 （除非您使用一些使用无状态模式的大容量 RP。）
根据您的功能集和用户界面，用户可能有一些其他会话状态，但这不需要应用于直接RP-OP 通信，您可以使用标准的技巧。
On the OP side, the only OpenID-specific state that really needs to be shared among the machines in your cluster is the associations (the shared secrets and their handles). And that's pretty cacheable; the secret for a given association handle never changes, they have a well-defined lifetime, and there shouldn't be that many of them. (Unless, perhaps, you operate with some high-volume RPs that use stateless mode.)
Depending on your feature set and user interface, there may be some other session state for the user, but that shouldn't need to apply to the direct RP-OP communications and you can use your standard bag of tricks.