CAS: One sign-on to rule them all!

CAS: One sign-on to rule them all!

CAS (Central Authentication Service) is an SSO protocol (Single Sign-On). The objective is to allow the user

CAS (Central Authentication Service) is an SSO protocol (Single Sign-On). The objective is to allow the user to enter various applications without the need to log in to each of them, but do it once.

How does this work? The idea is that when the user accesses one of these applications actually not authenticated in the application, he does through CAS. After authentication, the CAS server generates a ticket which is consulted by applications to determine the user’s status. As long as our meeting has a valid ticket, the CAS server will not ask us to return to enter it.

Additionally, a Central Authentication Service (CAS) server helps facilitate certain processes, such as creating the login pages in our applications, CAS counts just one as a common one for all.

In contrast to this, if our CAS server crashes, users of our applications cannot access them unless they have a valid ticket for the session. Additionally, we have a common problem in all SSO applications and shared computers, users forget to close their open sessions. If you do not log out, users that come later to use the computer can access many applications as the other person, even different applications than the ones the original user accessed.

One sign-on to rule them all!

When implementing a CAS server we decided to use this link. One of the things we liked is how easy it is to configure. With just a few commands and a couple changes of the lines in the configuration files, we have our Central Authentication Service server running in minutes.

A great advantage of CAS protocol is that it does limit us in terms of which technologies we can use. The server and the clients can be implemented in different languages just like different customers can also be implemented in different languages. The important thing is for everyone to respect the protocol. The difficulty lies in the existence of customer deployments in the chosen technology and the limitations of it in case we have to do it ourselves.

In this particular case, we decided to create a Ruby application with Sinatra and thus use an implementation provided by the same people as the server. Here we show how to authenticate against the CAS server in 5 Simple Steps.

  • Add ‘rubycas-client’ to your Gemfile.
  • Add the archive ‘cas_helpers.rb’ to your project.
  • In your archive .env, redefine APP_KEY as the group of applications that will share the log-in
  • In your archive .env add the following environment variables:
    • TICKET_STORE_DIR it is advisable to set to tmp directory
    • CAS_BASE_URL, must be set to point where it is hosted by our CAS server
      Add the following lines of code to your application
  • Add ‘ rubycas -client ‘ to your Gemfile:

 

before do 
  process_cas_login(request, session) 
  require_authorization(request, session) unless logged_in?(request, session) 
end

 

No related posts.