Simple Sso - Using Custom Authentication - Cas or Some Oauth or Openid Server

Simple SSO - using custom authentication - CAS or some Oauth or openid server?

Oauth is designed to authenticate application to let them act in the name of a user. For example a twitter client may post tweets with the account of a user. It can be used for single sign on as Facebook shows, but this requires a bit of additional work.

Comparing CAS and OpenID

CAS is a centralized system with one account authority. OpenID is a distributed system where basically anyone can setup an identity provider. Of course you can limit your consumer to only accept your own identity provider.

OpenID has two (incompatible) standards to provide additional attributes about the account, which are supported more or less by the common libraries. In the standard setup CAS only provides the username. While CAS does support attribute exchange in theory, at the moment only the PHP client supports it.

Both OpenID and CAS can do automatic login. If the user is already logged in, the browser will be redirected back to your application immediately. In a simple setup the identity provider, however, will display a login page, if the user is not logged in. So if you want to allow anonymous access to your side, this will require people to click a dedicated login link.

Luckily both OpenID and CAS allow a transparent login attempt. In this mode, the login form is not shown. The browser is redirected back immediately with or without authentication information. In other words: You can redirect all new users (without a session) to the identity provider as soon as they visit your site. There is a nice diagram explaining this in detail. CAS calls it "gateway mode" and it is achieved by appending gateway=true to the login URL. In OpenID it is called "immediate mode" and the URL parameter is openid.mode=checkid_immediate

CAS supports single sign out. OpenID does not.

My personal experience is that CAS is very easy to set up and very reliable with high quality libraries for all common programming languages. OpenID has many tiny incompatibilities as it is a much more complex system. OpenID, however, allows the usage of Google accounts.

Answers

First of all, I don't understand the need for token verifications of CAS, what is it good for?

Both OpenID and CAS require you to let the identify provider verify the provided token. Otherwise an attacker may be able to create his own token or use a token that was created by a user before he logged out.

Should clients also use ssl?

Yes.

On the client side, would you use an iframe, like lightbox, to show the redirected page? Why/Why not?

A full screen redirect is the most simple thing to do. I would start with that to get it working. Many application require a reload of the current page after login anyway in order to show parts that are only visible to logged in users.

An Iframe has the issue that you need to get rid of it once the login was completed. For CAS there is a tutorial on how to directly embed the CAS login form into the HTML code of the application. Another alternative is to show a pop up window like Facebook Connect does.

SSO with CAS or OAuth?

OpenID is not a 'successor' or 'substitute' for CAS, they're different, in intent and in implementation.

CAS centralizes authentication. Use it if you want all your (probably internal) applications to ask users to login to a single server (all applications are configured to point to a single CAS server).

OpenID decentralizes authentication. Use it if you want your application to accept users login to whatever authentication service they want (the user provides the OpenID server address - in fact, the 'username' is the server's URL).

None of the above handle authorization (without extensions and/or customization).

OAuth handles authorization, but it is not a substitute for the traditional 'USER_ROLES table' (user access). It handles authorization for third-parties.

For example, you want your application to integrate with Twitter: a user could allow it to tweet automatically when they update their data or post new content. You want to access some third-party service or resource on behalf of a user, without getting his password (which is obviously unsecure for the user). The application asks Twitter for access, the user authorizes it (through Twitter), and then the app may have access.

So, OAuth is not about Single Sign-On (nor a substitute for the CAS protocol). It is not about you controlling what the user can access. It is about letting the user to control how their resources may be accessed by third-parties. Two very different use-cases.

To the context you described, CAS is probably the right choice.

[updated]

That said, you can implement SSO with OAuth, if you consider the identity of the user as a secured resource. This is what 'Sign up with GitHub' and the likes do, basically. Probably not the original intent of the protocol, but it can be done. If you control the OAuth server, and restrict the apps to only authenticate with it, that's SSO.

No standard way to force logout, though (CAS has this feature).

Combining CAS with OAuth

That's certainly valid. OAuth 2.0 doesn't specify/dictate how the user (Resource Owner) is authenticated and CAS/SSO is fine for that. Effectively you'd be leveraging a CASified Authorization Server so that the Resource Owner authenticates with CAS to the Authorization Server, which is "just" an application to the CAS SSO system. The Authorization Server would then issue an access token down to the Client so that the Client can use that access token to access the protected resources i.e. the REST services.

Login Persistence across SSO Protocols with CAS

CAS4 has support for SAML, OAuth2 and OpenID 2.0. CAS5 has support for OpenID Connect, etc.

Let's be slightly more accurate that CAS4 has basic support for SAML1.1 and OAuth2 and its SAML2 support is limited only to handling an integration with Google Apps. Some have managed to extend it beyond that capability and turn it into a more general-purpose SAML2 integration strategy

CAS5 on the other hand as you note has support for SAML2 and OpenID Connect and a more improved version of OAuth2. The CAS protocol and related REST API implementations also gain quite a number of improvements in the way of working with JWTs as service tickets, etc.

I am wondering if one application authenticates with CAS via the CAS Protocol and a second subsequent application requests access via SAMPL or OAuth2 if the second application will be prompted to login, i.e. defeating the "Single Sign On" feature/capability?

No. That is the purpose of Single Sign-On. Regardless of what protocol you use, SSO/Authentication will continue to work fine because these are different subsystems. The thing that speaks a protocol language and the thing that validates credentials and the thing that creates and manages an SSO session all are very much independent of each other. If you find the opposite to be true in practice, that is a defect that needs a diagnosis.

I recommend you take a look at this blog post:
https://apereo.github.io/2018/02/26/cas-delegation-protocols/

Cross browser SSO with CAS

CAS provides support for token-based authentication on top of JWTs, where an authentication request can be granted an SSO session based on a form of credentials that are JWTs. CAS expects a token parameter (or request header) to be passed along to the /login endpoint as the credential. The parameter value must of course be a JWT. You can create this JWT and pass it to any browser, and you'll get a session back. See this for more info.

CAS vs. SAML vs. OAuth2

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

OpenId : Is true SSO possible?

OpenID Connect is an authentication protocol that supports "true" (whatever that means) SSO.

Read about it here: https://openid.net/connect/

Scenario 1: This is never how it works - RP2 will still need to make a roundtrip to the IP to get an identity token. But the user will not see a login screen and will sign-in automatically.

Scenario 2: Single Sign-out is part of the protocol - yes.

---

Related Topics