CAS - An Introduction

Home | Documentation | Support | Download | Get Involved | Related Sites

CAS - An Introduction

    CAS Introduction
    CAS Specification
    API Documentation

Table of Contents

Why CAS was created

A few years ago I was designing a database application. Back then I decided to let the DBMS (Oracle) authenticate my users which actually turned out to be a good decision since Oracle takes care of passwords and password restrictions, authorization to data and functions. Guess what!?! The application became a huge success. More departments rushed into it.

But the success came along with new interfaces to be built. Reports had to be implemented, data imports were planned, FTP uploads must be integrated. It turned out that each of the new components required users to authenticate and authorize against the application. But I didn't want them to get new passwords. Suddenly I had a problem: How do I authenticate them in Apache, Tomcat, FTP servers and Java applications?

The first approach was to implement an Apache module doing Oracle authentication. The C API provided by Oracle would meet the requirements and could be integrated into an Apache module. Soon I learned it was much more complicated then I initially thought. Java could do the work much better and easier than all the C stuff. Unfortunately, Java doesn't fit into Apache. I gave it up and tried JSP solutions.

Basically that worked. But there was one drawback: I had to implement the authentication process in each component, again and again. That was when I thought of a central authentication mechanism that could be requested by many components, programming languages and platforms.

How CAS works

CAS defines two components: a client and a server that exchange information about users. Clients send requests asking for authentication and authorization. Servers serves these requests, perform the necessary tasks to verify a user's credentials and reply with a success or denial message. Both components communicate over any channel, preferrably a TCP/IP connection, using a specific XML based protocol.

Clients are not required to have detailed knowledge about the type of authentication and authorization. They even don't know what requirements a user must fulfill to gain authorization. They just request authentication and authorization by sending an user's name, password and a string called Realm. This realm is a type of contract between client and server. Realms identify a specific procedure a specific server performs to authorize a user. You can think of Realms as names a developer defined when designing his application.

CAS itself does not define what procedures or authentication methods a client can request or a server must provide. CAS just defines how both communicate with each other - the CAS protocol.

So let's look at a simple example: Our client is a GUI that asks users for their name and password. Our server knows how users can be authorized. So, after launching the GUI a user must enter his name and password. When pressing the Login button, the GUI opens a connection to the server and send the following request:

<?xml version="1.0" ?>
Let's take a closer look into that request. We see at a quick glance that this is a XML document. Yes, that is true. All communication takes place as XML documents moving around. The client asks the server to authenticate alice with her password bob by applying a procedure called charlie.

Our server now checks if it has defined such a procedure charlie. It finds such a procedure and puts alice/bob into it. After verifying that alice is allowed to access our application, the server sends back a response - again a XML document:

<?xml version="1.0" ?>
Our server informs that alice is allowed to access the application (RC is true). Additionally, the server identifies itself as an ImportantServer V3.4.1.

In reality, more information can be exchanged such as cookies or error messages. But we wanted the example to be simple ;-) However, that's all it takes.

Now we want to add some more meat to it. The protocol defines several error codes that define certain errors occurring while performing such an authentication, e.g. when the server could not find the Realm or an information was missing. It can also give descriptive error messages back to our client so the message can be displayed to users.

CAS does not enforce the usage of encryption but it recommends to do so. Remember that requests contain clear passwords. However, if client and server sit on the same host and communication takes place just inside that host so no outsiders can interfere, then encryption would slow down the process and can be omitted. But if communication takes place over networks, then SSL encryption is defined as communication protocol.

Beside these authentication requests, CAS defines administration requests that clients can transmit to trigger a specific action on a server. This can be useful if you need to reload a configuration or shutdown the server. Server are not required to react on such requests. They also can simply deny execution. There is no definition of what kind of actions a server can perform.

You see that there is no magic anywhere. All it takes is a few XML messages that bounce back and forth.

Why CAS was designed the way it was

CAS was not specified as API's to be implemented or such things. CAS just defines a protocol two partners apply to gain authorization. No more - no less. This gives advantages you will learn to appreciate:
  • Clients don't need to know about authorization procedures. By burdening the actual authentication/authorization steps onto a server clients just need to implement the protocol to gain authorization. Everything else is hidden from clients.
  • Servers are free in their way implementing authentication and authorization. By hiding the way server authenticate/authorize from clients, servers can change these procedures whenever required. Clients are not affected in any way! Just think of the nightmare if one day my boss wants me to use DB2 instead of Oracle for my application.
  • Clients and servers are free how to implement the protocol. By just defining the protocol each party is free in its way how the goal is accomplished. Clients can use Perl, PHP, Java, C, Assembler, Tcl/TK, Smalltalk or whatever language currently has been hyped by journalists and programmers. Servers can run on Linux, Solaris, AIX, Windows or whatever hardware your controllers think is the cheapest. And of course vice versa - free hardware/OS choice for clients and language choice for servers. CAS can be compared with HTTP. Just remember how many different GUI's were created for webservers and how many webservers were programmed since HTTP emerged.
  • Security aspects are throughly considered. By transferring encryption to SSL, CAS does not try to re-invent the wheel. It leaves competency where it is best kept.
And best of all: You can centralize authentication/authorization to a minimum of costs.

What YOU can do

So how do you fit into the CAS scenario? Well, how about that:
  • Implement your own CAS server! There are hundreds of ways servers can be implemented. Each one has its own advantages, some are stable, other faster, next extendable, a.s.o. So if you feel that the existing servers do not fit your needs, start your own one!
  • Implement your own CAS client! There are hundreds of different programming languages and applications. All of them can be extended to work with CAS, either by using the C library libcas, or by writing a new, language specific library. So if you need to implement a new client, start your own one!

Known CAS implementations

Known CAS servers:

Name Description
JCas A Java based server that integrated JAAS and JDBC authentication

Known CAS clients:

Name Description
JCas The Java based server delivers a Java based client as well (Java class and JSP tag library for use in JSP's)
mod-cas An Apache module that integrates CAS into the famous webserver

Known CAS libraries:

Name Description
libcas C library for CAS clients