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. 
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
I follow a part of Apereo protocol, but I have changed some parts of that protocol.
Sign in: Has 3 flows
- Failed when credentials are incorrect
- Failed when user try to reuse the validation_ticket
the protocol suggest 2 ways to implement single log out:
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
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
- 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
- Logout from app server: clear session, redirect to log out from authentication server
- Coming soon…