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
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
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
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
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
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:
And best of all: You can centralize authentication/authorization to a minimum
- 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
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:
||A Java based server that integrated JAAS and JDBC authentication
Known CAS clients:
||The Java based server delivers a Java based client as well (Java class and JSP tag library for use in JSP's)
||An Apache module that integrates CAS into the famous webserver
Known CAS libraries:
||C library for CAS clients