CAS vs. SAML vs. OAuth2

Solution 1:

CAS-Server:

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.

(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.

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 process and you are expected to implement support for both.

OAuth 2.0:

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, 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.

Important Note :

SAML has 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.

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

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).

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.

When should I use which?

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

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

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

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

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

Reference 1,Reference 2,Reference 3

Solution 2:

If you need to authenticate for LDAP or ActiveDirectory then a solution like one of the CAS gems you mentioned above is right for you (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.

OAuth is 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.

If you are only intending to use HTTP POST for your SSO needs then the ruby-saml gem could be the way to go. You would have to implement your own Identity provider and add a service provider component 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 gem helps support writing API's in rails.

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.

The best way to share your authentication API is to implement an OAuth layer. Doorkeeper is 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.

Railscast for implementing doorkeeper

Solution 3:

Anjan.

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

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.

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.

Just my thoughts, and hope to hear more voices.