CAS与SAML与OAuth2相比

时间：2015-03-14 19:31:57

标签： ruby-on-rails oauth-2.0 single-sign-on saml cas

在你没有做任何作业的情况下让我问过于基本的问题之前，我想说我一直在做很多关于这些主题的阅读，但我仍然感到困惑。 / p>

我的需求似乎很简单。在我的公司，我们有一堆Ruby on Rails应用程序。我想构建一个SSO身份验证服务，所有这些应用程序都应该使用它。

尝试对如何执行此操作进行一些研究，我读到了CAS，SAML和OAuth2。 （我知道OAuth中的＆＃34; Auth＆＃34;代表授权，而不是身份验证，但我阅读了足够多的文章，说明OAuth如何用于身份验证 - this就是其中之一。）

有人能用简单的语言告诉我这三个是什么吗？他们是替代品（竞争）吗？比较它们甚至是正确的吗？

并且有很多宝石似乎都在说非常相似的东西：

我只想要一个单独的Rails应用程序来处理我的其他Rails应用程序的所有身份验证。

注意：我不想让用户使用他们的Google / Facebook帐户登录。我们的用户已在我们的网站上拥有帐户。我希望他们能够使用该帐户登录一次，并且无需再次登录即可访问我们的所有应用程序。在任何应用中注销都应该在所有应用中签名。

更新

我遇到过这两个OAuth解决方案：

他们似乎在描述与我想要的非常相似的东西。但我还没有找到任何指南/博客文章/教程，说明如何使用SAML / CAS执行此操作。

建议欢迎。

更新2

有关我们用例的更多详细信息。

我们没有任何现有的SAML架构。首先，我们的用户（直接在我们的网站上注册）将会访问我们的所有应用程序。将来，我们可能会有第三方（合作伙伴）公司调用我们的API。我们也可能有来自这些第三方（合作伙伴）公司（在其网站上注册）的用户访问我们的应用程序。

5 个答案:

答案 0 :(得分：48)

<强> CAS-服务器：

用户输入凭据（即用户名和密码）的独立中央登录页面。

  CAS支持标准化的SAML 1.1协议，主要是为了支持   属性发布到客户端和单点注销。

（SQL数据库中的表格，ActiveDirectory / LDAP，Google帐户等） 完全兼容开放的多平台CAS协议（CAS客户端适用于各种平台，包括 PHP，各种Java框架，.NET，Zope 等） 多语言本地化 - RubyCAS-Server自动检测用户的首选语言并显示相应的界面。

enter image description here

SAML ： 安全断言标记语言是一种基于XML的开放标准数据格式，用于在各方之间交换身份验证和授权数据，特别是在身份提供者和服务提供者之间。 SAML授权是一个两步流程，您需要对这两个流程实施支持。

enter image description here

OAuth 2.0 ：

OAuth 2.0授权框架支持第三方    应用程序以获得对HTTP服务的有限访问权限    代表资源所有者通过编排批准交互    资源所有者和HTTP服务之间，或通过允许    第三方应用程序以代表自己获取访问权。

enter image description here

重要提示：

SAML 有一个 OAuth2缺少的功能：SAML令牌包含用户身份信息（因为签名）。使用OAuth2，您无法获得开箱即用的功能，相反，资源服务器需要进行额外的往返以使用授权服务器验证令牌。

另一方面，使用 OAuth2，您可以在授权服务器上使访问令牌无效，并禁止其进一步访问资源服务器。

这两种方法都有很好的功能，两者都适用于SSO。我们已经用多种语言和各种应用程序证明了这两个概念。在一天结束时，OAuth2似乎更适合我们的需求（因为没有现成的SAML基础设施可供使用）。

  

OAuth2提供了一个更简单，更标准化的解决方案   我们目前的所有需求，并避免使用变通办法   与本机应用程序的互操作性。

我什么时候应该使用哪个？

1.如果您的用例涉及SSO（当至少一个参与者或参与者是企业时），则使用 SAML 。

2.如果您的用例涉及提供对资源（例如帐户，图片，文件等）的访问（临时或永久），请使用 OAuth 。

3.如果您需要提供对门户网站的合作伙伴或客户应用程序的访问权限，请使用 SAML 。

4.如果您的用例需要集中身份来源，请使用 SAML （身份提供商）。

5.如果您的用例涉及移动设备，那么带有某种形式的承载令牌的 OAuth2 是合适的。

enter image description here

<强> Reference 1 ，<强> Reference 2 ，<强> Reference 3

答案 1 :(得分：14)

如果您需要对 LDAP 或 ActiveDirectory 进行身份验证，那么上面提到的 CAS 之一的解决方案适合您（ RubyCAS，CASino）。

如果您能负担得起，其中一个商业供应商（如Okta）是您的最佳选择，因为他们将始终掌握安全补丁并管理您的身份验证需求。特别是，如果你必须支持ActiveDirectory，他们已经实现了它。

OAuth 对第三方身份验证最有用，但它可以执行SSO。因此，如果您想支持Google / Facebook登录或成为第三方身份验证器，那么这是一个很好的选择。由于您不想支持Google / Facebook，因此OAuth可能不是您想要的。

如果您只是打算使用HTTP POST来满足您的SSO需求，那么 ruby​​-saml gem可能就是您的选择。您必须实现自己的身份提供商并将服务提供商组件添加到您的所有网站（可能以gem的形式）。您需要的部分内容是rails api充当您的身份提供商。这个gem有助于支持在rails中编写API。

修改

您提到未来第三方用户可能登录您的网站的可能性。这会改变你的微积分，而不是滚动自己的ruby-saml解决方案。

分享身份验证API 的最佳方式是实施 OAuth 层。 Doorkeeper是一种流行的解决方案，并且正在迅速成为Rails身份验证的标准。它的社区支持，灵活性和易用性使其成为消费者认证API的最佳方式。

Railscast for implementing doorkeeper

答案 2 :(得分：9)

安键。

我在工作中使用了CAS和OAuth。以下是我的一些意见，希望能提供帮助。

基本上

  • CAS和SAML都旨在解决SSO问题。 CAS是一种服务或认证系统，可以支持SAML协议。
  • OAuth旨在解决授权和身份验证问题。

在实践中，

  • CAS和SAML都充当属于一个组织的一组应用程序前面的网关。就像你的情况一样。
  • OAuth用于在不同组织之间进行授权和身份验证。

只是我的想法，希望听到更多的声音。

答案 3 :(得分：1)

我们在我们的架构（移动应用程序，在线门户和微服务）中使用了CAS和SAML，两者都用于不同的目的。 我们的在线门户网站就像是在公共领域运行的网上银行，必须是安全的。我们不想将密码和其他安全令牌存储在在线门户的数据库中，因此，我们使用CAS进行身份验证和授权。在注册过程中，当用户选择密码时，我们将密码存储在CAS中，并将相应的令牌存储在Portal的DB中 用户下次登录时，用户在Portal中输入用户名和密码。 Portal从DB中获取与用户对应的令牌，并将User_name，password和token发送给CAS进行验证 但是，如果用户已经登录到一个应用程序并且我们将用户重定向到我们的另一个应用程序，那么我们不希望用户再次输入用户名和密码用于第二个应用程序。我们使用SAML来解决这个问题。第一个应用程序与SAML服务器共享用户详细信息并获取令牌。第一个应用程序将令牌传递给第二个应用第二个应用程序将令牌发送到SAML服务器以获取用户详细信息，并在成功时将用户移至所需页面我们的第一个应用程序可以是移动应用程序，第二个可以是App2Web场景中的Portal。

答案 4 :(得分：0)

由于您对此问题有很多答案，我想建议您一个身份产品，可以一手提供这些所有协议，具有大量的身份验证和用户管理功能。您可以为此尝试WSO2 Identity Server版本。

相关问题
最新问题