CAS - Shawn Bayern

indexadjustmentInternet and Web Development

Nov 13, 2013 (3 years and 11 months ago)

104 views

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)


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

Introducing CAS





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

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

Aggregating content


Aggregating authentication

Before

After

CAS in a nutshell

Browser


Web application

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)

How CAS really works

Web

resource

CAS

Web

browser

S

C

S

T

S

T

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

Side benefits of CAS


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


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

CAS examples





Low
-
level and high
-
level APIs
and tools

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

}

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>

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>

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

N
-
Tier Authentication





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

The goal


Portal


Web
-
mail


Channel


Mail server


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.

CAS’s solution:

proxiable

credentials

1.
During validation of ST, an application
acquires a
proxy
-
granting ticket

(PGT)

from CAS

2.
When the application needs access to a
resource, it uses the PGT to get a
proxy
ticket (PT)

3.
The application sends the PT to a back
-
end application.

4.
The back
-
end application confirms the PT
with CAS, and also gains information
about who proxied the authentication.


Proxiable credentials
illustrated

Web

resource

CAS

S

T

Non
-
web

resource

PGT

PGT

PT

PT

PT

-
Username

-
Identity of web resource

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.

CAS in context




How is CAS used at Yale?


Are there alternatives to CAS?

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

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
.

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

URLs


CAS distribution site


http://www.yale.edu/tp/cas/


Whitepapers


Design


Protocol


Source distribution


License information



My email address


shawn.bayern@yale.edu


Q&A


Alternative single sign
-
on systems?



CAS implementation questions?



Statistics?



Comments from schools already using
CAS?