Build your CAS - part 1

Recently, our application begins to scale up, and we have many separate services which are developed to satisfy different need of the customers. However, since we introduce all of them as a bundle, we need to somehow integrate all these separate services into single userbase without coupling the code together. The first step into that would be a single-sign-on service to centralize the authentication step. This is the first time I build this kind of SOA, or to be more trendy, microservices architecture, so I have a lot to learn. This is my personal note on the development of this service.

What is CAS?

CAS stands for Central Authentication Service, a single-sign-on protocol for the web. Its purpose is to permit a user to access multiple applications while providing their credentials (such as userid and password) only once. It also allows web applications to authenticate users without gaining access to a user’s security credentials, such as a password. [1]

Why CAS?

Beside CAS, there are other solutions, such as OpenID. However, CAS has some advantages which help you in some specific situations:

• It’s simpler than most of other solutions (again, openID) when building it yourself
• It’s suitable if you already have a userbase and want to build other services around that
• You don’t intend to make your service the “identity” checker for your user

Implementation

I follow a part of Apereo protocol, but I have changed some parts of that protocol.

Rough idea

Sign in: Has 3 flows

• Success

• Failed when credentials are incorrect

• Failed when user try to reuse the validation_ticket

Log out:

• the protocol suggest 2 ways to implement single log out:

  1. With in-memory ticket registry and cleaner: when we issue log out, we set the long live token to expired, then cleaner will issue a logout callback to the authentication service and all apps

  2. With distributed ticket registry and no cleaner: when we issue log out, we’ll redirect to authentication service logout url. In authentication service, the long-live-token will be exipired.

• We choose the distributed ticket registry with no cleaner. However, we currently haven’t use distributed ticket registry yet (we’ll consider it after a while). The ticket expiration checker currently goes through HTTP request.

• Implementation require 2 scenarios

  1. Logout from authentication server: clear session, then expire the long-live token. When app server try to check expiration of long live token, they will see that it’s expire, lead to app server automatically clears session

  

  1. Logout from app server: clear session, redirect to log out from authentication server

  

Detail

• Coming soon…

Reference

• [1] Wikipedia: Central Authentication service