The Central Authentication Service (CAS)

1. The Central Authentication Service (CAS) Shawn Bayern Research programmer, Yale University Author, JSTL in Action, Web Development with JavaServer Pages JSTL implementation lead (JCP, Apache)

2. Agenda • Introduction to CAS • Examples of CAS in action • N-tier authentication • Using CAS with applications like portals and web-based email • CAS in context • CAS at Yale • Alternatives to CAS • Summary, URLs, Q&A

3. Introducing CAS What is CAS, what does it offer, and how does it function?

4. What is CAS? • CAS is a single sign-on framework for • Web applications • Resources that web applications use (e.g., mail servers) • Why single sign-on? • Convenience and security (unlikely allies) • Users have to do less • Applications are protected from one another • Content aggregation

5. Before After Aggregating content → Aggregating authentication

6. CAS in a nutshell Authenticates via password (once) Determines validity of user’s claimed authentication Authenticates without sending password Browser Web application

7. Primary benefits of CAS • Works with existing authentication infrastructures, such as Kerberos • Can be used by nearly any Web-application development environment (JSP, Servlets, ASP, Perl, mod_perl, PHP, Python, PL/SQL, and so forth) — or as a server-wide Apache module • Allows "proxy" authentication for Web portals • Lets users authenticate securely to untrusted sites (e.g., student-run sites and third-party vendors) without supplying a password directly • Is portable (written in Java: Servlets, JSP, and JSTL) • Is freely available from Yale (with source code)

8. How CAS really works S T Web resource CAS S S T Web browser C

9. CAS requirements • CAS uses but does not require • JavaScript • For consistent, secure redirection • HTTP cookies • For single sign-on • CAS server requires Servlet 2.3, JSP 1.2 container

10. Users can be asked to avoid supplying password except to trusted site. Expected URL Known “look and feel” Authentic peer certificate (if anyone cares) Side benefits of CAS

11. Side benefits of CAS • Easy way to “reach” users • e.g., to require them to change password at regular intervals • Centralized maintenance • Can change many CAS details without changing client libraries • Unified authentication • Can manage smart cards, Kerberos, etc. from a single location

12. CAS examples Low-level and high-level APIs and tools

13. Example: Low-level API • Java Servlet that authenticates users import edu.yale.its.tp.cas.client.ServiceTicketValidator; ServiceTicketValidator sv = new ServiceTicketValidator(); sv.setCasValidateUrl( "https://secure.its.yale.edu/cas/serviceValidate"); sv.setService(“http://my/url”); sv.setServiceTicket(request.getParameter(“ticket”)); sv.validate(); if (sv.isAuthenticationSuccesful()) { System.out.println("user: " + sv.getUser()); // record authentication in HttpSession } Application must manage redirection to CAS itself

14. Example: Reusable CAS component • JSP page to authenticate users <%@ taglib prefix=“cas” uri=“…” %> <cas:auth var=“username” scope=“session”/> <p> Welcome, <c:out value=“${username}”/>. If you’ve gotten this far, you are authenticated. Come, make yourself at home. </p> Redirection occurs automatically

15. Example:Declarative CAS authentication in application server • Servlet 2.3 filter to assert requirement for CAS authentication <filter> <filter-name>CAS Filter</filter-name> <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name> <param-value>https://secure.its.yale.edu/cas/login</param-value> </init-param> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name> <param-value>https://secure.its.yale.edu/cas/proxyValidate</param-value> </init-param> </filter> <filter-mapping> <filter-name>CAS Filter</filter-name> <url-pattern>/filtered/*</url-pattern> </filter-mapping> Application simply retrieves username from HttpSession

16. Example: Declarative CAS authentication in web server • mod_cas for Apache 1.x, Apache 2.x • Username exposed as CGI environment variable, REMOTE_USER • Or… just protect static content • mod_cas supports “Require user X,Y,Z” and “Require group” in addition to “Require valid-user” AuthType CAS Require valid-user Server manages authentication. Application simply checks with server.

17. N-Tier Authentication How can we use CAS in portals, web-based email applications, and other scenarios where non-web resources provide secure data?

18. The goal • Channel • Mail server • Portal • Web-mail

19. The problem • Applications can authenticate users securely with CAS. • But applications don’t have first-hand knowledge of users’ credentials. • This is a good thing . . . • Except that the application can’t impersonate the user in order to acquire secure data for the user.

20. CAS’s solution: proxiable credentials • During validation of ST, an application acquires a proxy-granting ticket(PGT) from CAS • When the application needs access to a resource, it uses the PGT to get a proxy ticket (PT) • The application sends the PT to a back-end application. • The back-end application confirms the PT with CAS, and also gains information about who proxied the authentication.

21. Proxiable credentials illustrated S T Non-web resource Web resource CAS PGT PT PGT PT PT • Username • Identity of web resource

22. Characteristics of CAS’s solution • Back-end applications maintain control over their data • For instance, IMAP server may assert, “The only web-based email application I trust is https://www.mail.yale.edu/” • Default: no proxies allowed! • User logout or timeout destroys subordinate credentials • User must be “present” for proxied authentication to occur.

23. CAS in context How is CAS used at Yale? Are there alternatives to CAS?

24. CAS at Yale • Used by systems in support of students and administrators • Used occasionally by unprivileged students • Mostly Java and Perl; some ASP • Apache module used widely • Proxy authentication: incipient deployment • PAM module to be used with email servers • CAS to support uPortal deployment

25. Characteristics of alternative systems • Typically require pre-registration • Institution determines security requirements of services. • May handle more than just authentication • Session management • ACLs • Identification • Principal translation • May be platform- or server-specific • Passport (Windows) • Pubcookie • May depend on particular institutional characteristics—e.g., • Network topology • Service hosting on institutionally managed web servers CAS’s main advantages: simplicity and generality.

26. Summary • CAS… • is a free single sign-on framework from Yale • works with nearly all back-end authentication subsystems • provides secure authentication for both trusted and untrusted applications • CAS supports proxied authentication for applications like portals and web-based email

27. URLs • CAS distribution site • http://www.yale.edu/tp/cas/ • Whitepapers • Design • Protocol • Source distribution • License information • My email address • shawn.bayern@yale.edu

28. Q&A • Alternative single sign-on systems? • CAS implementation questions? • Statistics? • Comments from schools already using CAS?