Ruby-on-rails CAS 与 SAML 与 OAuth2

CAS vs. SAML vs. OAuth2

提问by Anjan

Before you put me down for asking too basic a question without doing any homework, I'd like to say that I have been doing a lot of reading on these topics, but I'm still confused.

在你因为我没有做任何功课就问太基本的问题而让我失望之前，我想说我已经对这些主题做了很多阅读，但我仍然感到困惑。

My needs seem simple enough. At my company, we have a bunch of Ruby on Rails applications. I want to build an SSO authentication service which all those applications should use.

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

Trying to do some research on how to go about doing this, I read about CAS, SAMLand OAuth2. (I know that the "Auth" in OAuth stands for authorization, and not authentication, but I read enough articles saying how OAuth can be used for authentication just fine - thisis one of them.)

试图做一些关于如何去做这件事的研究，我读到了关于CAS,SAML和OAuth2。（我知道 OAuth 中的“Auth”代表授权，而不是身份验证，但我阅读了足够多的文章，说明如何将 OAuth 用于身份验证就好了——这是其中之一。）

Could someone tell me in simple terms what these 3 are? Are they alternatives (competing)? Is it even right to be comparing them?

有人可以简单地告诉我这三个是什么吗？他们是替代品（竞争）吗？将它们进行比较是否正确？

And there are so many gems which all seem to be saying very similar stuff:

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

• https://github.com/rubycas/rubycas-serverand https://github.com/rubycas/rubycas-client
• https://github.com/nbudin/devise_cas_authenticatable
• https://github.com/onelogin/ruby-saml
• CASino and https://github.com/rbCAS/casino-activerecord_authenticator
• And I am sure there are hundreds of OAuth related gems.

• https://github.com/rubycas/rubycas-server和https://github.com/rubycas/rubycas-client
• https://github.com/nbudin/devise_cas_authenticable
• https://github.com/onelogin/ruby-saml
• CASino 和https://github.com/rbCAS/casino-activerecord_authenticator
• 而且我确信有数百个与 OAuth 相关的 gem。

I just want a separate Rails application which handles all the authentication for my other Rails apps.

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

Note:I do not want to allow users to use their Google / Facebook accounts to login. Our users already have accounts on our site. I want them to be able to login using that account once and be able to access all our apps without signing in again. Signing out in any app should sign them out of all apps.

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

UPDATE

更新

I have come across these two OAuth solutions:

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

• http://dev.mikamai.com/post/110722727899/oauth2-on-rails
• http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/

• http://dev.mikamai.com/post/110722727899/oauth2-on-rails
• http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/

They seem to be describing something very similar to what I want. But I haven't found any guide / blog post / tutorial showing how to do this with SAML / CAS.

他们似乎在描述与我想要的非常相似的东西。但我还没有找到任何指南/博客文章/教程来展示如何使用 SAML/CAS 做到这一点。

Suggestions welcome.

欢迎提出建议。

UPDATE 2

更新 2

More details about our use-case.

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

We do not have any existing SAML architecture in place. Primarily, it is going to be OUR users (registered directly on our website) who are going to be accessing all our applications. In the future, we may have third-party (partner) companies calling our APIs. We may also have users from these third-party (partner) companies (registered on their websites) accessing our apps.

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

采纳答案by Uri Mikhli

If you need to authenticate for LDAPor ActiveDirectorythen a solution like one of the CASgems you mentioned above is right for you (RubyCAS, CASino).

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

If you can afford it, one of the commercial vendors (like Okta) is your best option because they will stay on top of security patches and manage your authentication needs for you. In particular, if you have to support ActiveDirectory, they've already implemented it.

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

OAuthis most useful for third party authentication, though it can do SSO. So if you wanted to support Google / Facebook logins or be a third party authenticator then it's a great choice. Since you don't want to support Google / Facebook then OAuth is probably not what you want.

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

If you are only intending to use HTTP POSTfor your SSO needs then the ruby-samlgem could be the way to go. You would have to implement your own Identity providerand add a service providercomponent to all your websites (possibly in the form of a gem.) Part of what you would need is a rails api to act as your identity provider. This gemhelps support writing API's in rails.

如果您只想HTTP POST用于 SSO 需求，那么ruby-samlgem 可能是您的最佳选择。您必须实现您自己的身份提供者并向您的所有网站添加一个服务提供者组件（可能以 gem 的形式）。您需要的部分内容是作为身份提供者的 rails api 。这个gem有助于支持在 Rails 中编写 API。

EDIT

编辑

You mention the possibility that future third party users might be logging on to your site. This changes your calculus away from rolling your own ruby-saml solution.

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

The best way to share your authentication APIis to implement an OAuthlayer. Doorkeeperis a popular solution and is fast becoming the standard for Rails authentication. It's community support, flexibility and ease of use make it the best way to go for a consumable authentication API.

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

Railscast for implementing doorkeeper

用于实现门卫的 Railscast

回答by Tharif

CAS-Server:

CAS服务器：

A stand-alone central login page where the user enters their credentials (i.e. their username and password).

一个独立的中央登录页面，用户可以在其中输入他们的凭据（即他们的用户名和密码）。

CAS supports the standardized SAML 1.1 protocol primarily to support attribute release to clients and single sign-out.

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

(a table in a SQL database, ActiveDirectory/LDAP, Google accounts, etc.) Full compatibility with the open, multi-platform CAS protocol (CAS clients are implemented for a wide range of platforms, including PHP, various Java frameworks, .NET, Zope, etc.) Multi-language localization-- RubyCAS-Server automatically detects the user's preferred language and presents the appropriate interface.

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

SAML: Security Assertion Markup Language is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML authorization is a two step processand you are expected to implement support for both.

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

OAuth 2.0:

OAuth 2.0：

The OAuth 2.0 authorization framework enables a third-party applicationto obtain limited access to an HTTPservice, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

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

Important Note :

重要的提示 ：

SAMLhas one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don't get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.

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

On the other hand, with OAuth2 you can invalidatean access token on the Authorization Server, and disable it from further access to the Resource Server.

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

Both approaches have nice features and both will work for SSO. We have proved out both concepts in multiple languages and various kinds of applications. At the end of the day OAuth2 seems to be a better fit for our needs (since there isn't an existing SAML infrastructure in place to utilize).

这两种方法都有很好的特性，并且都适用于 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.

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

When should I use which?

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

1.If your usecase involves SSO (when at least one actor or participant is an enterprise), then use SAML.

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

2.If your usecase involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc), then use OAuth.

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

3.If you need to provide access to a partner or customer application to your portal, then use SAML.

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

4.If your usecase requires a centralized identity source, then use SAML(Identity provider).

4.如果你的用例需要一个集中的身份源，那么使用SAML（身份提供者）。

5.If your usecase involves mobile devices, then OAuth2with some form of Bearer Tokens is appropriate.

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

Reference 1,Reference 2,Reference 3

参考文献 1,参考文献 2,参考文献 3

回答by ifyouseewendy

Anjan.

安然。

I've used CAS and OAuth in my work. Here are some of my opinions, and hope to help.

我在工作中使用了 CAS 和 OAuth。以上是我的一些看法，希望对大家有所帮助。

Basically

基本上

• Both CAS and SAML aim to solve SSO situation. And CAS is a service or an authentication system, which can support SAML protocol.
• OAuth aims to solve authorization and authentication.

• CAS 和 SAML 都旨在解决 SSO 情况。而CAS是一种服务或认证系统，可以支持SAML协议。
• OAuth旨在解决授权和认证。

And in practice,

而在实践中，

• Both CAS and SAML act as an gateway in front of a group of applications which belong to one organization. Just like your case.
• OAuth is used to authorize and authenticate between different organizations.

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

Just my thoughts, and hope to hear more voices.

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

回答by ifyouseewendy

We have used CAS and SAML in our architecture (Mobile App, Online Portal, and MicroServices) and both are used for different purpose. Our Online Portal is like online banking that runs in public domain and has to be secure. We don't want to store password and other secure token's in the DB of the online portal, therefore, we use CAS for authentication and authorization. During registration, when user chooses the password, we store the password in CAS and store corresponding token in the DB of Portal
When user login next time, User enters the user name and password in Portal. Portal fetches the token corresponding to user from DB and sends User_name, password, and token to CAS for validation.
But, in case user has already logged in into one application and we redirect user to our another application then we dont want to user to enter username and password again for second application. We use SAML to solve this. First application shares user details with SAML server and gets token in return. First application passes the token to second application. Second application sends token to SAML server to get user details and on success lands user to desired page. Our first application can be Mobile App and second can be Portal in the scenario of App2Web.

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

回答by Harsha

Since you have got lot of answers for this question, I would like to suggest you an identity product that can be cater these kind of all protocol in one hand with lot of authentication and user management features. You can just try WSO2 Identity Server version for this.

由于您对这个问题有很多答案，我想向您推荐一种身份产品，它可以同时满足这些所有协议，并具有许多身份验证和用户管理功能。您可以为此尝试 WSO2 Identity Server 版本。