CAS - An Introduction

Table of Contents

• Why CAS was created
• How CAS works
• Why CAS was designed the way it was
• What YOU can do
• Known CAS implementations

Why CAS was created

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

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" ?>
<Request>
     <User>alice</User>
     <Password>bob</Password>
     <Scheme>charlie</Scheme>
</Request>

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" ?>
<Response>
      <RC>true</RC>
      <Server>ImportantServer/3.4.1</Server>
</Response>

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

• 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.

What YOU can do

• 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