3

在工作中，我们正在开发多个高度模块化的系统，它们之间不应存在硬依赖。现在我们需要这些系统共享一个通用的身份验证和安全机制——或者换句话说——SSO（单点登录）。很明显，我们将不得不制作另一个处理授权、身份验证和安全管理的模块——SSO 模块。关键是让它与我们的其他系统正确集成。

我能想到的两种方法是：

1) 从 SSO 公开一个 RESTful 服务，允许其他两个系统执行身份验证和授权操作。

2) 公开一个用于身份验证和授权的通用 API，它将包装我们的 SSO 功能并让两个系统引用该 API 并直接使用它。

目前我们没有考虑在这个领域使用任何第三方解决方案，并且我们已经在 will be SSO 模块上做了一些工作，所以我们更愿意坚持一个最能利用现有工作的简单解决方案。

我们应该选择哪种方法，为什么？每一个相对于另一个的显着优势是什么？有更好的选择吗？

4

1 回答 1

1

“我应该将其公开给 REST 还是将其封装在 API 中？”

追求两全其美。

  1. 将身份验证和授权模块公开为 RESTful 服务，以实现最大的互操作性，而不管为每个模块选择的语言、框架或平台如何。任何可以通过 HTTP 进行通信的东西都可以使用它。
  2. 然后用您选择的语言开发一个与您的 RESTful 服务通信的库；这将使多个模块更容易使用集中式身份验证机制。因此，您将拥有用 ruby​​、java 等编写的小型客户端，具体取决于您用于模块的语言。

这种代码重用是面向服务架构的关键租户之一，在我看来也是要走的路。根据我们在 BrightTag 和其他公司的经验，我和几位同事在最近的一次演讲中更深入地描述了这一点。

许多像CAS这样的“企业”SSO 系统使用非常相似的方法（尽管 CAS 协议不是 RESTful）。如果你想要更高级的功能，我肯定会给 CAS 看看。

于 2012-10-19T02:20:04.187 回答