CAS 与 SAML 与 OAuth2
CAS vs. SAML vs. OAuth2
在你因为我没有做任何功课就问了太基本的问题而让我失望之前，我想说我已经阅读了很多关于这些主题的资料，但我仍然感到困惑。
我的需求似乎很简单。在我的公司，我们有一堆 Ruby 申请 Rails。我想构建一个所有这些应用程序都应该使用的 SSO 身份验证服务。
为了研究如何做这件事，我阅读了 CAS、SAML 和 OAuth2。 （我知道 OAuth 中的 "Auth" 代表授权，而不是身份验证，但我阅读了足够多的文章，说明 OAuth 可以如何用于身份验证——this 就是其中之一。）
有人能简单地告诉我这 3 个是什么吗？他们是替代品（竞争）吗？比较它们是否正确？
而且有很多宝石似乎都在说非常相似的东西：
- https://github.com/rubycas/rubycas-server and https://github.com/rubycas/rubycas-client
- https://github.com/nbudin/devise_cas_authenticatable
- https://github.com/onelogin/ruby-saml
- 赌场和https://github.com/rbCAS/casino-activerecord_authenticator
- 而且我确信有数百个与 OAuth 相关的宝石。
我只想要一个单独的 Rails 应用程序来处理我的其他 Rails 应用程序的所有身份验证。
注意： 我不想让用户使用他们的 Google / Facebook 帐户登录。我们的用户已经在我们的网站上拥有帐户。我希望他们能够使用该帐户登录一次，并且无需再次登录即可访问我们所有的应用程序。在任何应用程序中注销应该将他们从所有应用程序中注销。
更新
我遇到过这两个 OAuth 解决方案：
- http://dev.mikamai.com/post/110722727899/oauth2-on-rails
- http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/
他们描述的似乎与我想要的非常相似。但我还没有找到任何指南/博客 post / 教程来展示如何使用 SAML / CAS 执行此操作。
欢迎提出建议。
更新 2
有关我们用例的更多详细信息。
我们没有任何现有的 SAML 架构。首先，访问我们所有应用程序的将是我们的用户（直接在我们的网站上注册）。未来我们可能会有第三方（合作）公司调用我们的API。我们也可能有来自这些第三方（合作伙伴）公司（在其网站上注册）的用户访问我们的应用程序。
安然.
我在工作中使用过 CAS 和 OAuth。以上是我的一些看法，希望对大家有所帮助。
基本上
- CAS和SAML都是为了解决SSO的问题。而CAS是一种服务或认证系统，可以支持SAML协议。
- OAuth旨在解决授权和认证。
在实践中，
- CAS 和 SAML 都充当属于一个组织的一组应用程序前面的网关。就像你的情况一样。
- OAuth 用于在不同组织之间进行授权和身份验证。
只是我的想法，希望听到更多的声音。
如果您需要为 LDAP 或 ActiveDirectory 进行身份验证，那么一个解决方案就像 CAS gem你上面提到的是适合你的（RubyCAS，CASino）。
如果您负担得起，其中一家商业供应商（如 Okta）是您的最佳选择，因为他们会随时提供安全补丁并为您管理身份验证需求。特别是，如果您必须支持 ActiveDirectory，他们已经实现了它。
OAuth 对于第三方身份验证最有用，尽管它可以进行 SSO。因此，如果您想支持 Google / Facebook 登录或成为第三方身份验证器，那么它是一个不错的选择。由于您不想支持 Google / Facebook，因此 OAuth 可能不是您想要的。
如果您只打算使用 HTTP POST 来满足您的 SSO 需求，那么 ruby-saml gem 可能是走。您必须实施自己的 Identity provider 并向所有网站添加 service provider 组件（可能采用 gem.) 您需要的一部分是 rails api 作为您的 身份提供者 。 gem 有助于支持在 rails.
中写入 API
编辑
您提到未来的第三方用户可能会登录到您的网站。这会使您的微积分不再滚动您自己的 ruby-saml 解决方案。
共享 身份验证 API 的最佳方式是实施 OAuth 层。 Doorkeeper 是一种流行的解决方案，并且正在迅速成为 Rails 身份验证的标准。它的社区支持、灵活性和易用性使其成为消费型身份验证的最佳方式 API。
CAS 服务器:
一个独立的中央登录页面，用户可以在其中输入他们的凭据（即他们的用户名和密码）。
CAS supports the standardized SAML 1.1 protocol primarily to support
attribute release to clients and single sign-out.
（SQL 数据库中的 table，ActiveDirectory/LDAP，Google 帐户等）
与开放的多平台 CAS 协议完全兼容（CAS 客户端为广泛的平台实现，包括 PHP、各种 Java 框架、.NET、Zope, 等等)
多语言本地化 -- RubyCAS-Server 自动检测用户的首选语言并呈现适当的界面。
SAML :
安全断言标记语言是一种基于 XML 的开放标准数据格式，用于在各方之间，特别是在身份提供者和服务提供者之间交换身份验证和授权数据。
SAML 授权是一个两步过程，您应该实现对两者的支持。
OAuth 2.0:
OAuth 2.0 授权框架支持 第三方
application 以获得对 HTTP 服务的有限访问权限，或者
通过编排批准交互代表资源所有者
在资源所有者和 HTTP 服务之间，或者通过允许
第三方应用程序代表自己获取访问权限。
重要提示：
SAML 具有 OAuth2 所缺乏的一项功能：SAML 令牌包含用户身份信息（由于签名）。使用 OAuth2，您无法开箱即用，相反，资源服务器需要进行一次额外的往返以使用授权服务器验证令牌。
另一方面，使用 OAuth2，您可以使授权服务器上的访问令牌无效，并禁止它进一步访问资源服务器。
这两种方法都有不错的特性，并且都适用于 SSO。我们已经用多种语言和各种应用程序证明了这两个概念。归根结底，OAuth2 似乎更适合我们的需求（因为没有现成的 SAML 基础设施可供利用）。
OAuth2 provides a simpler and more standardized solution which covers
all of our current needs and avoids the use of workarounds for
interoperability with native applications.
我应该什么时候使用哪个？
1.If 您的用例涉及 SSO（当至少一个参与者或参与者是企业时），然后使用 SAML.
2.If 您的用例涉及提供对资源（例如帐户、图片、文件等）的访问（临时或永久），然后使用 OAuth.
3.If 您需要向您的门户提供合作伙伴或客户应用程序的访问权限，然后使用 SAML.
4.If 您的用例需要集中式身份源，然后使用 SAML（身份提供者）。
5.If 您的用例涉及移动设备，那么 OAuth2 和某种形式的 Bearer Tokens 是合适的。
Reference 1,Reference 2,Reference 3
既然你对这个问题有很多答案，我想向你推荐一个身份产品，它可以在一方面满足这些所有协议的需求，并具有许多身份验证和用户管理功能。您可以为此尝试 WSO2 身份服务器版本。
我们在我们的架构（移动应用程序、在线门户和微服务）中使用了 CAS 和 SAML，并且两者用于不同的目的。
我们的在线门户就像在 public 域中运行的网上银行，并且必须是安全的。我们不想在在线门户的数据库中存储密码和其他安全令牌，因此，我们使用 CAS 进行身份验证和授权。注册时，当用户选择密码时，我们将密码存储在CAS中，并将相应的token存储在Portal的DB中
用户下次登录时，用户在Portal中输入用户名和密码。 Portal从DB中取出用户对应的token，将User_name、密码、token发送给CAS进行验证
但是，如果用户已经登录到一个应用程序并且我们将用户重定向到我们的另一个应用程序，那么我们不希望用户再次为第二个应用程序输入用户名和密码。我们使用 SAML 来解决这个问题。第一个应用程序与 SAML 服务器共享用户详细信息并在 return 中获取令牌。第一个应用程序将令牌传递给第二个应用程序。第二个应用程序将令牌发送到 SAML 服务器以获取用户详细信息，并成功将用户登陆到所需页面。我们第一个应用可以是Mobile App，第二个可以是App2Web场景下的Portal。
在你因为我没有做任何功课就问了太基本的问题而让我失望之前，我想说我已经阅读了很多关于这些主题的资料，但我仍然感到困惑。
我的需求似乎很简单。在我的公司，我们有一堆 Ruby 申请 Rails。我想构建一个所有这些应用程序都应该使用的 SSO 身份验证服务。
为了研究如何做这件事，我阅读了 CAS、SAML 和 OAuth2。 （我知道 OAuth 中的 "Auth" 代表授权，而不是身份验证，但我阅读了足够多的文章，说明 OAuth 可以如何用于身份验证——this 就是其中之一。）
有人能简单地告诉我这 3 个是什么吗？他们是替代品（竞争）吗？比较它们是否正确？
而且有很多宝石似乎都在说非常相似的东西：
- https://github.com/rubycas/rubycas-server and https://github.com/rubycas/rubycas-client
- https://github.com/nbudin/devise_cas_authenticatable
- https://github.com/onelogin/ruby-saml
- 赌场和https://github.com/rbCAS/casino-activerecord_authenticator
- 而且我确信有数百个与 OAuth 相关的宝石。
我只想要一个单独的 Rails 应用程序来处理我的其他 Rails 应用程序的所有身份验证。
注意： 我不想让用户使用他们的 Google / Facebook 帐户登录。我们的用户已经在我们的网站上拥有帐户。我希望他们能够使用该帐户登录一次，并且无需再次登录即可访问我们所有的应用程序。在任何应用程序中注销应该将他们从所有应用程序中注销。
更新
我遇到过这两个 OAuth 解决方案：
- http://dev.mikamai.com/post/110722727899/oauth2-on-rails
- http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/
他们描述的似乎与我想要的非常相似。但我还没有找到任何指南/博客 post / 教程来展示如何使用 SAML / CAS 执行此操作。
欢迎提出建议。
更新 2
有关我们用例的更多详细信息。
我们没有任何现有的 SAML 架构。首先，访问我们所有应用程序的将是我们的用户（直接在我们的网站上注册）。未来我们可能会有第三方（合作）公司调用我们的API。我们也可能有来自这些第三方（合作伙伴）公司（在其网站上注册）的用户访问我们的应用程序。
安然.
我在工作中使用过 CAS 和 OAuth。以上是我的一些看法，希望对大家有所帮助。
基本上
- CAS和SAML都是为了解决SSO的问题。而CAS是一种服务或认证系统，可以支持SAML协议。
- OAuth旨在解决授权和认证。
在实践中，
- CAS 和 SAML 都充当属于一个组织的一组应用程序前面的网关。就像你的情况一样。
- OAuth 用于在不同组织之间进行授权和身份验证。
只是我的想法，希望听到更多的声音。
如果您需要为 LDAP 或 ActiveDirectory 进行身份验证，那么一个解决方案就像 CAS gem你上面提到的是适合你的（RubyCAS，CASino）。
如果您负担得起，其中一家商业供应商（如 Okta）是您的最佳选择，因为他们会随时提供安全补丁并为您管理身份验证需求。特别是，如果您必须支持 ActiveDirectory，他们已经实现了它。
OAuth 对于第三方身份验证最有用，尽管它可以进行 SSO。因此，如果您想支持 Google / Facebook 登录或成为第三方身份验证器，那么它是一个不错的选择。由于您不想支持 Google / Facebook，因此 OAuth 可能不是您想要的。
如果您只打算使用 HTTP POST 来满足您的 SSO 需求，那么 ruby-saml gem 可能是走。您必须实施自己的 Identity provider 并向所有网站添加 service provider 组件（可能采用 gem.) 您需要的一部分是 rails api 作为您的 身份提供者 。 gem 有助于支持在 rails.
编辑
您提到未来的第三方用户可能会登录到您的网站。这会使您的微积分不再滚动您自己的 ruby-saml 解决方案。
共享 身份验证 API 的最佳方式是实施 OAuth 层。 Doorkeeper 是一种流行的解决方案，并且正在迅速成为 Rails 身份验证的标准。它的社区支持、灵活性和易用性使其成为消费型身份验证的最佳方式 API。
CAS 服务器:
一个独立的中央登录页面，用户可以在其中输入他们的凭据（即他们的用户名和密码）。
CAS supports the standardized SAML 1.1 protocol primarily to support attribute release to clients and single sign-out.
（SQL 数据库中的 table，ActiveDirectory/LDAP，Google 帐户等） 与开放的多平台 CAS 协议完全兼容（CAS 客户端为广泛的平台实现，包括 PHP、各种 Java 框架、.NET、Zope, 等等) 多语言本地化 -- RubyCAS-Server 自动检测用户的首选语言并呈现适当的界面。
SAML : 安全断言标记语言是一种基于 XML 的开放标准数据格式，用于在各方之间，特别是在身份提供者和服务提供者之间交换身份验证和授权数据。 SAML 授权是一个两步过程，您应该实现对两者的支持。
OAuth 2.0:
OAuth 2.0 授权框架支持 第三方
application 以获得对 HTTP 服务的有限访问权限，或者
通过编排批准交互代表资源所有者
在资源所有者和 HTTP 服务之间，或者通过允许
第三方应用程序代表自己获取访问权限。
重要提示：
SAML 具有 OAuth2 所缺乏的一项功能：SAML 令牌包含用户身份信息（由于签名）。使用 OAuth2，您无法开箱即用，相反，资源服务器需要进行一次额外的往返以使用授权服务器验证令牌。
另一方面，使用 OAuth2，您可以使授权服务器上的访问令牌无效，并禁止它进一步访问资源服务器。
这两种方法都有不错的特性，并且都适用于 SSO。我们已经用多种语言和各种应用程序证明了这两个概念。归根结底，OAuth2 似乎更适合我们的需求（因为没有现成的 SAML 基础设施可供利用）。
OAuth2 provides a simpler and more standardized solution which covers all of our current needs and avoids the use of workarounds for interoperability with native applications.
我应该什么时候使用哪个？
1.If 您的用例涉及 SSO（当至少一个参与者或参与者是企业时），然后使用 SAML.
2.If 您的用例涉及提供对资源（例如帐户、图片、文件等）的访问（临时或永久），然后使用 OAuth.
3.If 您需要向您的门户提供合作伙伴或客户应用程序的访问权限，然后使用 SAML.
4.If 您的用例需要集中式身份源，然后使用 SAML（身份提供者）。
5.If 您的用例涉及移动设备，那么 OAuth2 和某种形式的 Bearer Tokens 是合适的。
Reference 1,Reference 2,Reference 3
既然你对这个问题有很多答案，我想向你推荐一个身份产品，它可以在一方面满足这些所有协议的需求，并具有许多身份验证和用户管理功能。您可以为此尝试 WSO2 身份服务器版本。
我们在我们的架构（移动应用程序、在线门户和微服务）中使用了 CAS 和 SAML，并且两者用于不同的目的。
我们的在线门户就像在 public 域中运行的网上银行，并且必须是安全的。我们不想在在线门户的数据库中存储密码和其他安全令牌，因此，我们使用 CAS 进行身份验证和授权。注册时，当用户选择密码时，我们将密码存储在CAS中，并将相应的token存储在Portal的DB中
用户下次登录时，用户在Portal中输入用户名和密码。 Portal从DB中取出用户对应的token，将User_name、密码、token发送给CAS进行验证
但是，如果用户已经登录到一个应用程序并且我们将用户重定向到我们的另一个应用程序，那么我们不希望用户再次为第二个应用程序输入用户名和密码。我们使用 SAML 来解决这个问题。第一个应用程序与 SAML 服务器共享用户详细信息并在 return 中获取令牌。第一个应用程序将令牌传递给第二个应用程序。第二个应用程序将令牌发送到 SAML 服务器以获取用户详细信息，并成功将用户登陆到所需页面。我们第一个应用可以是Mobile App，第二个可以是App2Web场景下的Portal。