超媒体 (ReST) SOA：一致的服务级别身份验证的良好设计？
我目前正在开发一个 SOA 解决方案，其中架构中的每个服务都是安全的、经过身份验证的超媒体资源（就像在真正的超媒体中一样，而不是具有漂亮 URL 的 RPC）。
面向客户、公司内部和客户构建的应用程序将构建在此架构之上（这没什么不寻常的）。我不能假设应用程序之间存在通用的身份验证模式，因为用户识别和凭证管理的要求可能存在很大差异。
由此可见，架构中的服务必须采用单独的身份验证方案。理想情况下，这在服务（例如 HMAC）之间应该完全一致，以允许尽可能多的客户端/服务器模块重用。
我向您提出的问题是：是否有一种通用模式可以跨解耦服务提供一致的身份验证和凭证管理？如果是这样，那是什么？
我提出了一些想法，但如果有经验丰富的工程师提供意见，我们将不胜感激：
1)每个服务都公开一个离散但机械上相同的身份验证接口，并且负责自己的凭证管理。
2) 与 1) 相同，但具有共享凭证管理。架构中的每个服务仍然公开离散的身份验证接口，如1)，但底层数据介质是共享的。
3) 有一个共享身份验证服务，负责自身和所有其他服务的身份验证和凭证管理。
我发现想法2)是最吸引人的，但它需要一些改进。除非我在这里完全走错了路。
请大家多多批评/建议。当然要记住，这是关于设计而不是实现；目前我对框架/中间件/协议 XYZ 不感兴趣。
对散文表示歉意，并感谢您的阅读。
I'm currently developing an SOA solution, where each service in the architecture is a secure, authenticating hypermedia resource (as in really hypermedia, not RPC with pretty URLs).
Customer-facing, company-internal and customer-built applications will be built on top of this architecture (nothing unusual here). I cannot assume that there exists a common authentication pattern between applications because requirements for user identification and credential management can differ significantly.
It follows that services in the architecture must employ a separate authentication scheme. Ideally this would be completely consistent between services (for example HMAC), to allow as much client/server module re-use as possible.
My question to you is this: is there a common pattern for providing consistent authentication and credential management across decoupled services? If so, what is it?
I came up with a few ideas, but input from more experienced engineers would be appreciated:
1) Each service exposes a discrete but mechanically identical authentication interface, and is responsible for its own credential management.
2) As 1) but with shared credential management. A discrete authentication interface is still exposed for each service in the architecture, as in 1), but the underlying data medium is shared.
3) There is a single shared authentication service, which is responsible for authentication and credential management for itself and all other services.
I find idea 2) to be the most appealing, but it needs some refinement. Unless I am totally on the wrong track here.
Please criticise/suggest as much as you see fit. Bearing in mind of course that this is about design and not implementation; I'm not interested in framework/middleware/protocol XYZ at this point.
Apologies for the prose, and thanks for reading.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
LDAP 是 -->从而集中凭证。
亚马逊的 AWS 身份验证方案已在那边上线。每个应用程序都可以实现该功能并参考 LDAP 获取凭据。
如果您愿意，OAuth 已在此处启动集中整个套件。
只是澄清一下，这不应该是一个思想实验。已经完成了，没有理由重做。四处寻找标准并实施它们。与 LDAP 交互的东西有很多。 AWS 是一个临时标准，但它可以完成工作并回答大多数人的问题，并且已经过审查，发现了缺陷并进行了修复，并且在我们发言时已被许多人广泛使用。如果您想去那里，OAuth 可以帮助解决中央身份验证问题。
LDAP is --> that away to centralize credentials.
Amazons AWS authentication scheme is up and over yonder. Each app can implement that and refer to the LDAP for credentials.
OAuth is up and over here if you want to centralize the entire kit.
Just to clarify, this should NOT be a thought experiment. It's been done, no reason to redo it. Look around for standards and implement them. The things that talk to LDAP are legion. AWS is an ad hoc standard, but it does the job and answers most everyones questions, and has been vetted, found to be flawed and fixed, and is in use in the wild by many as we speak. OAuth helps solve the central authentication problems if you want to go there.