RAZPRAVE
B ESUP-Portail: open source Single Sign-On with CAS (Central Authentication Service)
Pascal Aubry1, Vincent Matter', Julien M arch a I'' 11FStC. University of Hennas 1, France, pascal.aubry@univ-rennes1 .fr ^University of Nancy 2, France,
vincent.mathieu@univ-nancy2 fr. |ulien mgrchal@univ-nancy2 fr
Abstract
The universality of thu HTTP pruLocol seduced developers fur quite u lung time; in fact, today, most applications are web-based L DAP directories may make life easier on our users' brains by making them memorize only one password, but their fingers are still very busy with all the authentications they need to type — in practice, each time they access an application. Many solutions for Single Sign-On fSSOl are already available. In this article, we describe a free, simple, complete and reliable solution: the CAS (Central Authentication Service), developed by Yale University (New Haven, CT; USA). CAS has been chosen by the French ESUP-Portail consortium, which provides a complete and open solution to Universities and University-level colleges who wish to offer integrated access tn their services and information fur their students and staff. Keywords: Single Sign-On (SSO), open-source, authentication
Povzetek
ESUP-Portail; odprtokodna rešitev problema enkratne prijaue i uporabo CAS
Univerzalnost protokola HTTP že dolgo privlači razvijalce tako. da danes do večine aplikacij dostopamo po svetovnem spletu. Direktoriji vrste LOAP nam prihranijo miselni napor, ker omogočajo, da si je potrebno zapomniti le eno geslo, vendar imajo prsti še vednu "polne roke dela", ker je potrebno geslo vnašati večkrat - v praksi vsakič, ko dostopamo do neke aplikacije.
Za enkratno prijavo (Single Sign-On ali SSO) obstaja več rešitev. V pričujočem članku opišemo odprtokodno. enostavno, popolno in zanesljivo rešitev, ki se ji pravi CAS (Central Authentication Service), razvita pa je bila na univerzi Yale (New Haven, Connecticut t, ZDA). CAS uporablja tudi francoski konzorcij ESUP-Portail, ki ponuja odprtokodno in popolno rešitev naloge zagotavljanja integriranega dostopa do storitev in informacij na univerzah in visokih šolah s strani Študentov in zaposlenih. Ključne besede: enkratna prijava. odprLa koda, avtentikacija.
1 Why do we need Single Sign-On?
UVeb-based applications (mailers, forums, agendas, other specific applications) have spread widely over our networks during recent years. These applications often require authentication.
Using I.DAP directories provides users with a single account, which is obviously a real improvement. I knvever, some issues remain: . Multiple authentications: it is still necessary to
give a net Id/password for each application; - Security: because user accounts are unique, password stealing is really a critical problem; for this reason, the security of the authentication process is essential. In addition, security concerns indicate that user credentials should no longer be given to applications.
• Several authentication mechanisms: there are a variety of authentication mechanisms. I .DAI1 is one widely used standard today, but it can be replaced by other user databases. In addition, some users possess personal X509 certificates [1[, which can be used for authentication. In any case, bypassing authentication mechanisms would be interesting because it would permit the use of mixed authentication, for instance.
■ Cooperation: particularly in the educational community, close institutions would like to be able to share resources and applications. Such cooperation implies that users should be identified by an establishment when only authenticated with another one.
2004 šlevilka A ■ Iclnik XII
gpimiiii informatika 187
Pascal Aubry, Vincenl Mathieu, Julien Marchai ËSUP-Portail: open source Single Sign-On with CAS (Central Authentication Service!
• Authorization; applications often need to know user profiles to allow (or deny) the performance of specific actions.
The principle of all SSO solutions is to remove authentication from the applicative code. The goal is then to offer a globally secured software environment:
r-W- —«¡>
I upp, #1 | app. app. #3
M/
web browser
without SSO
| sprvjciTj Î
app. #1 j ' app. »2 app. #3 J
VI/
web browser
With SSO
Figure 1: The principle of Single Siyn-On
Most SSO mechanisms [2| try to achieve this goal using similar techniques:
• Authentication is centralized via an encrypted tunnel in a unique server, which is the only machine to receive user credentials; . HTTP redirections are sent from applications to the authentication server for unaulhenticated users, and then back to the applications once a user is authenticated; ■ Information is passed by the authentication server to applications during the redirections, via cookies [3| and/or CGI parameters. Among the commercial solutions offered to system administrators and developers, two leaders stand out: Sun One Identity Server [4| and Microsoft Passport [5]. However, because the ESUP-Portail project is based on open-source software only, neither of these commercial solutions was a feasible choice for this project {however, none of them was fitting to our needs). After testing several free implementations, the ESUP-Portail SSO group chose CAS (Central Authentication Service [61, developed by Yale University) for its Single Sign-On mechanism.
2 The reasons why we chose CAS
We chose for a number of reasons. CAS is made up of java servlets, can be run on any (JSP spec 1.2 compli-
ant) servlet engine, and offers a web-based authentication service. Its strong points include security, and flexibility, as well as its proxying features and numerous client libraries.
2.1 Security
Security is insured the following ways:
• Passwords are always sent through an encrypted tunnel, and pass only from the browser to the authentication server (Figure 2);
• Re-authentications are transparent to users, providing that they accept a single cookie, called the Ticket Granting Cookie' (TGC). This cookie is opaque (no personal information), protected (HT-Tl'S) and private (only presented to the authentication server);
• Applications learn user identities from opaque one-time 'Service Tickets' (ST). Those tickets are emitted by the authentication server, transmitted to applications by the browsers, and finally validated by the authentication server (returning the corresponding identity). Thus, as it is the case for almost all serious SSO mechanisms, applications never see any password.
2.2 Flexibility
The package proposed by CAS developers offers a complete implementation of the authentication protocol, but the authentication itself (against a user database) is left to the administrator. We wrote a generic handler that provides several connectors (LDAP, X509 certificates, NIS domains, databases). These connectors can be used separately, or they can be used in combination to permit mixed authentication. This generic
uur
l.i'^ database
I service .-► H B
î rn
»PP [«pp. »2, 0PP.*3
M/
w#b browser
without SSO
^ aorvic® j
© î
i #1 app *?
jsy
?. app »3 [ ailrenicit'o-ll
web browser
with CAS
Figure 2 A software environment secured by CAS
188 UPoniBut informatika
2004- številka i - letnik XII
Pascal Aubry, Virmpnl Mjihicu, Julien Marchai: ESUP-Portail: open source Single Sign-On with CAS [Central Authentication Service]
handler can also been extended to allow system administrators access to other authentication methods, such as Kerberos or Active Directory.
2.3 Authentication prettying
Classic SSO mechanisms demand direct communication between the browser and the application, which prohibits the use of multi-tier installations in which an application must request a back-end service requiring authentication (for instance, a portal requesting a web service),
CAS v2,() solves this problem by providing an elegant way to propagate authentication without propagating passwords; dedicated tickets {PGT: Proxy Granting Ticket and PT: Proxy Ticket) ensure the validity of user identities to third-party applications. This feature is obviously the strongest point of CAS, inherited from Kerberos concepts.
2.4 Client libraries
The code that handles the basic protocol (apart from proxying) is very simple to write on the client-side (applications). CAS provides Client libraries for Perl, Java, ASP and PL/SQL. We added a strong (proxy-able) PHP library. These libraries make it possible to CAS-ify existing applications by simply adding a few lines of code, offering an impressive degree of flexibility.
An Apache module (mod cas) lets web servers authenticate users for static resources, since client libraries can not be used in such circumstances.
A PAM (Pluggable Authentication Module [7[) module (pam cas) allows non web-based applications to be integrated at a very low level.
2.5 Moreover...
In addition to the reasons described above, CAS has another overwhelming argument in its favor: it is used by many American Universities, in conjunction with LDAPor Kerberos-based authentication, making us confident of its durability over time.
Even better, CAS can be plugged directly into uP-ortal [8], (used in the ESUP-Portail) which is on the way to becoming a standard for open source portals.
This article shows how Single Sign-On is achieved with CAS, and focuses on a precise technical issue: CAS-ifying a webmail (Horde IMP) and an IMAP server (Cyrus IMAP).
3 How CAS works
3.1 Architecture
3.1.1 The CAS server
Authentication is centralized on a single machine, called the CAS server. This machine is the only actor that knows user passwords. It has a double role: » Authenticating users;
■ Transmitting and certifying the identities of authenticated users to CAS clients,
3.1.2 Vlleb browsers
Web browsers must meet the following requirements to take advantage of all CAS's easy features. They must:
• Own an encryption engine so that it can use HT-TPS;
• Perform HTTP redirections (access a URL given by a Location header when receiving 30x responses) and understand basic Javascript;
« Store cookies, as defined in S3C. In particular, for security purposes, private cookies should be transmitted only to the machines that emitted them. These requirements are met by all classic web browsers, such as Microsoft Internet Explorer (since 5.(J), Netscape Navigator (since 4,7) and Mozilla.
3.1.3 CAS clients
A web application equipped with a CAS client library, or a web server using modjeas, is called a CAS client. It delivers resources only to clients previously authen-licated by the CAS server. CAS clients include:
• Libraries, compatible with the most widely used web-programming languages (Perl, Java; ISP, PHP, ASP);
■ An Apache module, used in particular to protect static documents;
> A I'AM module, used to perform system level authentication.
3.2 Basic operating procedure 3.2.1 User authentication
A previously non-authenticated user (or a user whose authentication has expired) accessing the CAS server
2004 - Btëuilka £ - letnik XI!
uporabm* informatika 189
Pascal Aubry. Vincent Mathieu. Julien Marchai: ESUP-Portait: open source Single Sign-On with CAS [Central Authentication Service]
is presented with an authentication form, on which (s)he is invited to enter a netld and a password (Figure 3).
CAS server
wob browser
Figure 3 first access of a browser ta the CAS server
Figure 5 flsdirection □! an unknown browser to the CAS semer
If the netld and password are correct, the server sends a cookie called TGC (Ticket Granting Cookie) to the browser (Figure 4).
e-
user database
CAS
server
natu password
wob browser |
-trec|
Figure A Authentication of a hromser against the CAS server
This TGC is the user's passport to the CAS server, its validity is limited, typically to a few hours. The TGC allows web browsers to get CAS client tickets from the CAS server, without needing to re-authenticate. A private cookie that is transmitted only to the CAS server, it is also protected ensuring that all requests to the CAS server are secured. Like all CAS tickets, it is opaque, containing no information about the user. !t is simply a session identifier operating between Ihe web browser and the CAS server.
3.2.2 Accessing protected web resources after authentication
When accessing a resource protected by a CAS client, the web browser is redirected to the CAS server. The browser, if previously authenticated, presents its TGC to the CAS server (Figure 5).
On presentation of the TGC, the CAS server delivers a Service Ticket (ST), an opaque ticket providing no user information, that is usable only by the service that asks for it. At the same time, the CAS server re-
directs the browser to the calling service (the Service Ticket is a CGI parameter) (Figure 6),
cas server
application
\ÏÈ\ : E :
; X ;
s
Figure C Redirection of the browser to the calling service after authentication
The ST is then validated by the CAS client with the CAS server (via an HTTP request) and the desired resource can be delivered to the browser (Figure 7).
CAS server
[ÏÇ?ï SfsT] : P :
; X ;
.....i st ]•«■
•S...»
application
---
Figure 7 Validation of a Service Ticket
19û u * n « * a » « informatisa
200¿ - stevilka /. - letnik XU
Pascal Aubry. Vincenl Malhieu. Julien Marchalr ESUP-Portail: open source Single Sign-On with CAS [Centrât Authentication Service)
All the redirections mentioned above are transparent for the user: (s)he accesses the resource without being authenticated, without any interaction at all (Figure 8).
Figure 8 User uiew a! the CAS redirections
The Service Ticket (ST) is the browser's passport to a CAS client. This One-Time Ticket can not be presented twice to the CAS server, is valid only for the CAS client to whom it was delivered, and can be used only for a very short period of lime (typically a few seconds).
3.2.3 Accessing protected web resources without authentication
The non-authenticated web browser attempting to access a resource protected by a CAS client is still redirected to the CAS server. As no TGC is given, the CAS server returns an authentication form.
Once the browser has submitted the form and is correctly authenticated, the CAS server:
• Sends the browser a TGC, that will exempt it from re-authenticating later;
• Provides a Service Ticket and redirects the browser to the CAS client calling service.
Thus, there is no need to be previously authenticated to access a protected resource; authentication is automatically performed the first time a user requests a protected resource.
3.3 Multi-tier installations
3.3.1 CAS proxies
The CAS multi-tier feature makes it possible for a CAS client to access a back-end service under the authenticated user's identity. A CAS client that is able to
proxy credentials is called a CAS proxy. Most used CAS proxies are:
• Web portals, which need to access external applications (web services [91 for instance) under user identities;
- Wcbmail applications, which need to connect to an (MAP server to retrieve email under user identities.
In a multi-tier CAS installation, CAS clients no longer have access to the browser's cookie cache, and so redirections can not be used.
3.3.2 2-tier installations
A CAS proxy, when validating a Service Ticket to authenticate a user, also asks for a PGT (Proxy Granting Ticket) from the CAS server (Figure 9).
CAS server
.................m
®......
application (CAS proxy)
Figure 9: PGT retrieval by a CAS prony
A PGT is the CAS proxy's passport, representing a user, to the CAS server. It allows the CAS proxies to obtain tickets for CAS back-end services from the CAS server, without needing to validate an ST. The PGT is an opaque and re-playable ticket, delivered by the CAS server in response to a secured request, to insure TGC integrity and confidentiality. PGT validity is limited, like that of TGC, to a few hours.
PGT are to applications what TGC are to web browsers. A PGT allows applications (CAS proxies) to authenticate a user with the CAS server, and to obtain Proxy Tickets (I'T are to CAS proxies what ST are to web browsers). Proxy Tickets, like Service Tickets, are validated by the CAS server before allowing access to protected resources (Figure 10).
3.3.3 N-tier installations
Obviously, the back-end service accessed by the CAS proxy in 2-tier installation can itself be a CAS proxy, CAS proxies can be chained, as shown in Figure IX.
200/. - številka k - letnik XII
up0rî8n* informatika 191
Pascal Aubry, Vincenl Mathieu. Julien Marchai; ESUP-Portail: open source Single Sign-On wilh CAS (Central Aulhcnl italien Service)
CAS server
service '
........ \
'••■H-1 \
. { • • :pot
application (CAS proxy)
Figure 10: Ualidatinn ni a Proxy Ticket by a back-end service
4.1 The GenericHandler class
Developed by the ESUP-Portail project [10], the GenericHandler class [111 allows the implementation of many authentication methods: LDAP directories, databases, NIS {Unix Yellow Pages), NT domains, etc. Furthermore, this class can be easily extended to fit other needs (Novell, Kerberos, Active Directory, etc.).
The configuration is done in an XML format, in which one or more authentication methods are specified. They are sequentially tested until one succeeds.
Because LDAP lias become the standard for storing and authenticating users, we provide an example of how Generic Handler can be used with an LDAP directory.
4.2 Authentication using an LDAP directory
Two different access modes are proposed, depending on the internal structure (DIT) of the LDAP directory.
At this time, CAS is the only open-source and free SSO mechanism that allows n-tier installations without propagating user passwords.
4 CAS user authentication
The original CAS distribution does not include user authentication. If such authentication is needed, authentication classes can be written by administrators to fulfill their cxacl needs. Some example classes are provided by the cas-server distribution, for test purposes only.
4.2.1 Direct access mode (idap fasthind)
Idap fastbind mode can be used with LDAP directories in which user DN (Distinguished Name) can be directly deduced from their netld. In practice, these are directories in which users are stored at the same hierarchical level, in the same OU for instance.
In this case, CAS tries to connect the directory using the DN and password provided by the user. Classically, the user is authenticated if the connection succeeds.
web browser
CAS proxy #1
CAS proxy #2
service
Figure 11 A chain gf MS proxies
CAS server
T
1
Í
T
LDAP
directory
databases
T
NIS domain
X509 certificates
T
Kerberos domain
Windows NT domain
file
Figure 12 User authentication with ESUP-Portail CenericHanrilcr
192 uporaína informatika
7004 - stevilka U - letiiik XII
Pascal Aubry, Vincent Mathieu, Mien Marchal. ESUP-Portail; open source Single Sign-On with CAS [Central Authentication Service)
The following configuration can be used: ^authentication:.*
1.2.2 Search mode (Idap bind)
When the DN can not be deduced from the netld, administrators must use the Idapbind mode to seek out the user's DN before attempting a connection.
The following configuration can be used: authentications cldap version="3" timeout="5">
< /authentications
4.2.3 LDAP Redundancy
Generic Handler permits redundancy in order to be more fault-tolerant: it is possible to specify a list of I DAP servers, which are considered as replicas.
5 CflS-ifying a vueb application
CAS-ifyiug a web application is very easy, thanks to CAS client libraries.
Three kinds of CAS applications exist:
• CAS "simple" clients only need to authenticate
users.
• CAS proxies need to both authenticate users, and use tier services. They need to be able to retrieve PGT from the CAS server, and later to transmit PT to back-end services in order to authenticate the users for whom they act.
• CAS back-end services need to validate the PT given by CAS proxies and to obtain user identities.
5.1 "simple" CAS clients
The principle is to use a function (or method) that will run the authentication mechanism and return the user's netld. This function must perform the following tasks:
- If the user is not already authenticated and no ST is provided, redirect the web browser to the CAS server (providing its own URL for redirection as shown in 3.2.2); ■ If tiie user is not already authenticated and a ST is provided, validate the ST by using an HTTPS request to the CAS server. The CAS server should then return the corresponding user's netld. To illustrate the simplicity of the CAS-ification of such a "simple" CAS client, we show below how a CAS client can be written in PI IP. Of course, in a real application, a client library in our case, phpCAS J12] -should be used instead.
5.1.1 Writing a PHP CAS client
If this script (script.php) is called without any parameter, it redirects the web browser to the CAS server, giving its own URL as a CGI parameter: https://cas.univ. tr/login?service=htlp://test. univ.fr/script.php
The user is authenticated with the CAS server, which redirects the browser to the calling service, giving a ST as a CGI parameter. The access UliL would be something like:
http://test.univ.fr/script,php?ticket=ST-2 uw2KEWinSFeZ9iotZiio
Our script will then try to validate the Service Ticket with the CAS server, by accessing the following URL:
http(s)://autfi.univ.fr/serviceValidate?service=http:// test.univ.fr/script.php&ticket=ST-2-uw2KEWinSFeZ9fotZlio
The CAS server validates the ticket and returns the user's netld, in an XML response:
paubry |mis\ Spage))
{
if (preg_match(' |(.*Xcas: user-l Spage ,$matcti)){ return($match[1]);
}
}
// validation failed return FALSE:
}
if ((Slogin = authenticate«) === FALSE ) { echo 'failure (Retry).'; exit();
}
echo 'welcome user '.SIogin'!
'
echo '(
5.1.2 Using the phpCAS client library
The phpCAS library 112] was developed by the ESUP-Portail project. Here is one way that it can be used:
User is c?php echo phpCAS::getUser(); ?x/bo,