Yale CAS 快速入门

再摘抄一篇关于CAS的入门级文章，这篇文章比较浅显易懂，并对各种CAS Client做了介绍，对于集成不同类型的应用系统有一定的帮助。

When to Use CAS

The Central Authentication Service (CAS) is the standard mechanism by which web applications at Yale should authenticate users. Any custom applications written by ITS or other groups within Yale benefit from using CAS. Third-party applications customized for Yale should be modified to use CAS whenever possible.

Note that CAS provides authentication; that is, it determines that your users are who they say they are. CAS should not be viewed as an access-control system; in particular, providers of applications that grant access to anyone who possesses a Yale NetID should understand that loose affiliates of Yale may be granted NetIDs.

The Easiest Way to Use CAS

In many cases, using CAS requires no new programming to protect either static web content or dynamic web applications. On systems that run the Apache HTTP Server (either version 1.x or version 2.x), a runtime module (mod_cas) is available to provide CAS authentication to the entire server (or a configurable subset of the server's content). While CAS simply authenticates users, this module provides both authentication services and access-control services: it lets you grant access to specific users and groups. It even lets users on your servers authenticate users and restrict access via local .htaccess files.

The Apache module is part of the standard client distribution and is in wide use at Yale and elsewhere. A runtime CAS module for Microsoft's IIS (i.e., an ISAPI filter) has been written by developers at Indiana University and is available for experimentation, though we don't have as much experience with this filter as we do with the Apache module. Contact ITS Technology and Planning for assistance with the ISAPI filter if you're interested.

If you write Java applications against the Servlet 2.3 and JSP 1.2 standards, you might also be interested in a servlet filter that implements CAS authentication. Like the Apache module, this filter lets you declare authentication requirements without writing custom code, and it works wherever your Java servlets or JSP pages run; that is, it does not require Apache. The CAS servlet filter is part of the same client distribution supported by Technology and Planning.

A Programmer's View of CAS

If you decide that the Apache module, servlet filter, or other declarative mechanism is insufficient for your needs, you will need to write a small amount of custom code to handle authentication programmatically. Technology and Planning provides numerous client libraries to support a wide variety of programming languages, and CAS implements an open protocol that is accessible from any modern computing environment.

Before you begin to integrate your application with CAS, however, you should understand a few details about the way CAS operates. First and more importantly, CAS is unlike many familiar authentication systems because it is not simply a password-validation tool. In a traditional environment, your web application will ask users for an ID and a password, and it will then call logic to determine whether this ID/password pair is valid. With CAS, however, your application never gains access to the user's password; to improve systemwide security, users supply their passwords only to the CAS server directly.

Therefore, using CAS in your application may be more circuitous than you initially imagine, though be assured that the process is still straightforward and easy to master. When you first encounter a new user (e.g., one that has not yet established a session with your application), you'd normally display a username/password form in HTML. With CAS, you don't do this; instead, you simply redirect the browser to CAS's login URL, which is

https://secure.its.yale.edu/cas/login

CAS then authenticates the user. If authentication fails -- e.g., if the user cannot supply a correct password -- then you'll never hear from the user again. (At least, you won't hear formally through any CAS protocol!) Instead, the user will remain at CAS's site and will have the option to choose various "help" links that point to the ITS User Accounts Office, which is responsible for NetID credentials.

Only if a user succesfully authenticates does that user's browser return to your application. Specifically, the user returns because CAS redirects the browser back to your application. CAS knows how to find your application because when you initially redirected the user to CAS, you supplied a service parameter, in the form

https://secure.its.yale.edu/cas/login?service=http://my/url

(Note that any metacharacters in your service URL, such as question marks, ampersands, and equals signs, must be escaped appropriately using the standard URL encoding algorithm: %26 for &, %3D for =, and %3F for ?. This will be necessary if your service URL contains parameters of its own. Note also that while it is necessary that you use HTTPS to safeguard your own application's authentication in secure environments, CAS's overall security is not weakened if your application merely uses HTTP; instead, CAS still authenticates the user securely, and then it relays this fact to your application in a best-efforts fashion.)

When CAS redirects the authenticated user back to your application, it will append a parameter named ticket to your URL. For instance, the URL you supplied CAS may be called as follows:

http://my/url?ticket=ST-92834-m34Aa83f7a3f

We call this ticket opaque because, unlike an X.509 certificate or a Kerberos TGT, it is not possible for your application to decipher its meaning in isolation or from first principles. It has no internal structure useful to your application. The only thing you can do with this ticket is to send it back to CAS, which involves opening an HTTPS connection to

https://secure.its.yale.edu/serviceValidate

and sending two query parameters: service, which must match the service URL you initially supplied to CAS when redirecting the user there, and ticket, which is the ticket you just received. CAS then responds either with an explicit refutation of this ticket (think "it's not meaningful to me and does not represent a valid user") or an acknowledgement that the ticket proves authentication. In the latter case, CAS also supplies the user's NetID so that you know the identity of the user.

Note that this final connection to CAS occurs directly between your application and CAS; your application opens a socket connection and retrieves information from the CAS server. You do not redirect the browser; you speak directly to CAS, effectively closing the loop and completing the authentication process. The CAS client libraries focus on making this HTTPS communication simple in a variety of languages; you don't need to know details about how to write an SSL or HTTPS client, nor do you need to know any details about how CAS's response is formatted textually (though this information is documented fully in two architectural papers if you're curious.

Available Client Libraries

As I've emphasized, numerous client libraries are available to assist you in programmatically integrating CAS authentication into your application. These libraries, available in the client distribution, include the following:

Java client

A complete and documented set of classes provides access to all of CAS's features. The servlet filter I mentioned earlier is included in this library, as is a JSP tag library that simplifies the use of CAS in environments that don't want to use the filter.

ASP example

A sample page written by Howard Gilbert demonstrates how to authenticate users in ASP without using the ISAPI filter.

Perl module

Drew Mazurek has written a Perl module that handles the initial redirection of the user and the validation of the ticket. Usage is simple: you just call a function from the top of each of your pages.

PL/SQL

A PL/SQL procedure from Andy Newman lets you authenticate a user from within an Oracle application.

PHP

PHP code from outside the University helps you integrate CAS with PHP; usage is similar to the Perl module.

What to Do Once You Authenticate a User with CAS

CAS is not a session-management mechanism; it provides no facility for helping you keep track of users once they're authenticated. Typically, applications will want to track users just as they would if they'd validated a user's password themselves. That is, you'll probably want to establish your own session -- using application-specific, in-memory cookies or a similar mechanism -- right after you validate a user's authenticity with CAS.

CAS is a single sign-on facility; once a user authenticates to CAS, the user need not continue to supply a password for other applications that redirect the user to CAS. However, CAS is not a "single sign-off" facility; a user that logs out of CAS will still have access to your application if your application keeps a persistent session with the user.

CAS does provide a "logout" URL that the user may visit; loading this URL causes CAS to forget about the user's prior authentication. Applications may link to this URL at

https://secure.its.yale.edu/logout

However, because users may intend to continue to use CAS (and other CAS-protected applications) after they finish using your application, it is considered inappropriate to redirect to this URL automatically or to otherwise suggest that all users visit this URL when they complete your application's flow. Instead, provide a link to this URL as an option and label it something like "You may log out of CAS." We may soon provide a "CAS logout logo" that will help encourage appropriate expectations from users.

Other Things CAS Can Do

CAS allows for multi-tier authentication, meaning that it facilitates intregration of protected applications into a campuswide portal and that it lets applications use back-end resources (such as an IMAP server) securely. For more information, see the architectural papers or contact Technology & Planning.

CAS also lets applications opt out of its single sign-on facility. For applications that consider their data especially sensitive, this facility may be appropriate to ensure that a CAS-authenticated user is still present and hasn't, for instance, walked away from a public kiosk. Note that using this feature makes it difficult to integrate your application into a campuswide portal and may disappoint users' expectations of single sign on. If you decide to use this option, it is documented at the end of the CAS 2.0 paper.