Central Authentication Service

Central Authentication Service
Scott Battaglia (Rutgers University) Andrew Petro (Yale University) Bill Thompson (Rutgers University)

What is CAS? CAS is Enterprise level single sign on for the web
A trusted source A proxy authenticator

Some CAS deployers Your school goes here.
There are many known CAS deployers, and we suspect there are more CAS deployers out there who are not yet listed on our CAS deployers Wiki page. CAS deployers primarily include universities but also include IT consultancies, newspapers, nonprofit organizations, and massively multiplayer online role playing games. Your school goes here.

History of CAS CAS 1.0 Created by Yale University Simple to use
Protocol was simple yes or no No proxy authenticaton

History of CAS CAS 2 Also produced by Yale University
Introduced Proxy authentication Simple implementation Few classes Extending CAS required modifying source code

History of CAS CAS 3.0 Collaboration between Yale University and Rutgers University Goal was to make it easy to extend CAS without modifying core code Completely compatible with CAS 2 protocol Leverages tried-and-tested open source software

Why CAS 3? CAS 2 was simple to use and understand
CAS 3 arguably is more complex, is it true? Why/why not? Introduce many “best practices” Position CAS for future enhancements Leverage knowledge gained working with other tools

New in CAS 3 Customizable login flow Pluggable architecture
Ticket Store Authentication Handlers More… Support for Web Services Support for alternative views

CAS in a nutshell Authenticates via password (once) Determines
validity of user’s claimed authentication Three players in CAS SSO. The end user at her web browser, the web application, and the CAS server (the scales in this picture). Authenticates without sending password Browser Web application

How CAS Works S T Web application CAS NetID S T Web browser C
(Play the animation a few times). The end user at the web browser visits the web application. She follows a link or the web application redirects to CAS. So the web application accesses the CAS login URL, presenting the service URL [S]. The user interacts with CAS until she convinces it of her identity (e.g., presents a session cookie or posts her username and password into a form). CAS establishes, if not yet established, a secure cookie [C] so that CAS can recognize the user on a subsequent request. CAS redirects the user to the web application service URL (S) with the service ticket [T] on the URL as the request parameter “ticket”. The web application presents the ticket [T] to CAS alongside the service identifier [S]. CAS responds with the [NetID] in the validation response. The application reads this NetID and does whatever it needs to do to establish an application session, service the request. T Web browser C

CAS Community Mailing Lists Wiki Issue Tracking
Continuous Integration Tools Maven CVS Frappr Non JA-SIG Communities

Mailing Lists Provide two mailing lists Developer User
User

Wiki Instance of Atlassian Confluence Provides
Provides Documentation Downloads etc

Issue Tracking Instance of Atlassian JIRA
Provides snapshot of project plan Fixed and outstanding bugs

Continuous Integration
Instance of Luntbuild Download nightly snapshots of CAS

Maven Site Publishes: Java docs Test Results Clover reports

Version Control CVS Repository Web View via FishEye
Anonymous checkout of any version of CAS Obtain latest code (bleeding edge) Web View via FishEye

Frappr

ESUP Portail French language CAS community
Produce quick starts and common tools French lists

Requirements to Deploy CAS
A server and network connection  A servlet container supporting Servlet 2.4/JSP 2.0 specification Certificate Java 1.4 or higher CAS 3.0.2

Download CAS CAS releases are available from the Wiki Available as
ZIP TAR GZ Starting with 3.0.3, include md5, SHA1 hash

Making your application use CAS (compellingly)
CAS Service Clients Making your application use CAS (compellingly) Slides for the CAS clients portion of the JA-SIG / uPortal conference pre-conference seminar on CAS3, June 2005 in Baltimore. Whirlwind tool of the available CAS service clients. Explanation of the Renew and Gateway CAS server features. Andrew Petro, Yale ITS,

CAS How to use CAS Abstraction Layer Your Application
So, there’s this CAS server that we’re giving this pre-conference seminar about. Great. And there’s an end user behind a web browser on a computer somewhere. Also great. Your application lives behind an abstraction layer, typically one provided by a CAS client, code you use to get the user to CAS authenticate and from which you get the results of the authentication. These slides are about available clients that provide that abstraction layer and the CAS features that those clients can leverage to provide a compelling user experience.

Many CAS Clients Acegi (for Java web-apps, esp. Spring)
AuthCAS (Perl Apache module) PerlCAS phpCAS There are many CAS clients. Acegi can serve as a CAS client in Java – it provides its own abstractions and API for you to write your application to (or not, and just declaratively wire in authN and authZ as Aspects…) and can use CAS as its backing authentication mechanism. AuthCAS is a Perl-implemented Apache authentication module. PerlCAS is a Perl library for using CAS, akin to the Java client library except for Perl. phpCAS is a PHP CAS service client library out of the ESUP-Portail group. phpCAS has been known to release fixes and improvements the day they are submitted for consideration… Impressive project.

Many More CAS Clients for Prado (a PHP framework)
for Seraph (a Java security framework) for uPortal for WebObjects For Zope Prado is a relatively new PHP framework for building web applications, and already there is a posted contribution of a Prado plugin to use CAS authentication. Seraph is the Java web application security framework used by JIRA and Confluence, and there’s posted code and instructions for backing it with CAS. uPortal is the focus of this conference and many schools use CAS to authenticate to uPortal. There’s a posted library for using CAS authentication in Apple WebObjects. There’s a posted contribution to the Zope environment to use CAS. And there’s posted example code for using CAS authentication in ColdFusion.

Yale CAS clients Java Servlet Filter Java Objects JSP tag library
MOD_CAS PAM_CAS ISAPI filter PL/SQL In addition to the previously mentioned Java CAS clients, Yale distributes a number of clients. The most featureful of these are the Java clients, including a Java Servlet Filter, low level CAS client Java objects, and a JSP tag library. Yale also distributes clients including an Apache module, a PAM module, an ISAPI filter, and a PL/SQL module.

Many Supported Platforms
Summarizes via collage of logos from previous slides. Acegi offers CAS as one of its backing options, there’s a ColdFusion example posted in our Wiki, ESUP-Portail uses CAS and distributes a number of excellent CAS resources, there’s a Zope plugin contribution for using CAS authentication with the Zope application container, uPortal is commonly CASified and Yale distributes some libraries to accomplish CASifying uPortal, AuthCAS is a Perl-implemented Apache module that uses CAS, Atlassian Seraph can be made to use CAS and there’s documentation in the Wiki on how to do this, there’s a WebObjects library to use CAS to authenticate to WebObjects, phpCAS is a PHP module for using CAS distributed by ESUP-Portail, and there’s a posted add-on for the Prado PHP web application framework that uses CAS.

Applications distributed CASified
Your Application Goes Here. uPortal isn’t distributed by JA-SIG CASified, but there’s an ESUP-Portail distribution that is CASified. It’s commonly and easily CASified via a uPortal-specific CAS security provider plugin. TikiWiki is CASified out of the box, offering CAS as one of the options for how users authenticate to TikiWiki. Mantis last I checked isn’t CASified out of the box but there’s a posted patch that adds the feature. PHP News Reader supports CAS for authentication. phpBB as distributed by ESUP-Portail uses CAS. Your application can use CAS. BlueSocket (!)

CAS Features for Services
Renew, Gateway, Proxy authentication The Renew and Gateway CAS server features.

Renew Opts out of Single Sign On
Advisory on /login (CAS always prompt for credentials) Security implications on /validate (tells CAS to only succeed validation if credentials were presented) The CAS renew feature is the mechanism whereby an application opts out of Single Sign On at runtime. On /login the application advises CAS Server that this is its preference so that CAS can provide an appropriate user experience (require the user to present credentials). At ticket validation the service indicates this configuration so that CAS will only successfully validate service tickets that were acquired by presentation of primary credentials.

Gateway Tells CAS to redirect back without a ticket if one cannot be acquired non-interactively (e.g., via an established SSO session). Allows you to provide the best user experience possible under the circumstances. Gateway is in some sense the opposite of renew. It tells CAS to redirect back to the service immediately, without interrupting the user experience with a login screen. Gateway means that CAS may redirect back without a service ticket, if it could not obtain one non-interactively. Gateway allows your application to provide the best user experience possible under the circumstances as soon as possible – if you can authenticate the user non-interactively then you can immediately display authenticated, personalized information, but if the user has not yet logged into a CAS single sign on session, your application still has an opportunity to do its best to serve the user even before the user logs in.

Public Portal For example, suppose we have a Portal. The Portal has a public user experience that feels a lot like a newspaper. It’s generic, public, non-authenticated information. We use a Portal for this because we’re still doing interesting “portal-stuff”, aggregating content from different sources, caching, etc. This generic information page is of greater than zero value to many users: often a user won’t need to log in, because the link or information she needed was right there on the generic page.

Authenticated Portal This same portal also provides an authenticated user experience, reflecting user preferences, group memberships, attributes, and personalized and private information we can only get at when the user has authenticated. The authenticated user experience presents a superset of the public view. The authenticated information is more valuable to the user than the generic non-personalized information was.

First request to the portal
So now we have a problem: on our user’s first request to our portal, she will always see the generic, guest information. Even if she’s already established a CAS SSO session, we won’t be aware of this, so we won’t log her in. So she has to click the login link. We’ve missed an opportunity to provide the user a more valuable experience sooner. How will we solve this?

CASify all requests Well, we could require CAS authentication from the very beginning, on the first request for the portal. In the case where the user has already logged into CAS, on her very first request for the portal we’ll redirect her to CAS, it will redirect back with a ticket, we’ll validate the ticket, authenticate the user, and provide her her highest-value, personalized, authenticated user experience.

Login Screen However, if she hasn’t established an SSO session already, instead of providing the valuable guest user experience and generic portal information, we’ve sent her to a CAS login screen. If she doesn’t have a NetID, she can’t get through to the public information. Even if she does have a NetID, we’ve made logging in a requirement to see public information. No good.

But I just wanted the weather…
If the user just wanted to see the weather and didn’t need the authenticated user experience, we’ve now needlessly inconvenienced the user.

Needlessly locking public information
This is what it’s like when we require CAS authentication to access public information such as the weather, public announcements, convenient links, library and directory and Yale search, the calendar, etc.

Effective use of Gateway
Effective use of Gateway solves this problem for us. By opting into the Gateway feature, we instruct CAS to redirect the user back whether or not authentication was possible without further user interaction. If CAS redirects back without a ticket, we’ll know that the generic, guest user experience is the best we can do without asking the user to log in. If CAS comes back with a ticket, we can authenticate the user and present the authenticated, personalized user experience, providing maximum value on the very first response to the user from the portal. Most valuable to the user is the authenticated, personalized content. Second most valuable is the public, generic, guest content. Last choice is a login screen. Authenticated, personalized content Public, generic content Login screen

Why am I telling you this?
CAS Server offers a few primitives Upon which you can build compelling user experiences Renew and Gateway are “advanced” tools in the toolkit. Why present the Renew and Gateway features today? To convey the idea that CAS provides a few primitives, a small featureset upon which you can build (or the CAS client libraries can build) compelling user experiences. Renew and Gateway are two “advanced” CAS features in this toolkit.

Proxying authentication
Another “advanced” tool in the toolkit More on this later. Proxy authentication is another, very powerful tool in this toolkit, one which is covered in more detail in another piece of this pre-conference seminar.

CAS Clients everywhere…
This cute fellow (Prado mascot?) can use CAS, and so can you, by use of one of the distributed CAS service client libraries, or even via new code written to play the service client role in the CAS protocol.

That was SSO * Lots of SSO solutions out there CAS is a nice one
They all look and work more or less just like CAS for SSO purposes. * There are interesting conversations to be had about and additional needs and opportunities in SSO. The CAS gateway feature is an opportunity to provide a maximally valuable “first screen” in a particular user session with Sakai. SSO adds value to links out of Sakai into other systems and makes compelling links into particular sites / tools / content in Sakai. SSO is more valuable the better it handles the case where an SSO session is not yet established (prompt me to login and when I’m done logging in bring me back to what I was trying to access in the first place.)

CAS 2.0: Proxy CAS PGT PGTIOU S T PGTURL Web application CAS NetID
https listener S T PGTURL Web application CAS NetID PGTIOU S In order for an application to proxy authentication to other applications, it first validates a service ticket as we described before. The user accesses the web application (say, Sakai). Sakai redirects or provides a link to CAS /login, specifying the Sakai URL as the [S] service. CAS authenticates the user somehow (recognizes a SSO session cookie, receives a valid username, password pair, etc.) CAS redirects back to the service with the service ticket [T]. The web application (Sakai) validates the service ticket [T] and service identifier [S] pair with CAS. Additionally, the web application (Sakai) presents to CAS an https: callback url [PGTURL]. CAS issues an HTTP GET to that callback URL, presenting a [PGT], [PGTIOU] pair. CAS returns in the validation response the authenticated user name [NetID] and the [PGTIOU]. The web application can use that PGTIOU to lookup the PGT. It thereby authenticates itself as the endpoint of the proxy callback URL. Only the application listening on that https URL can lookup the PGT given the PGTIOU. Okay, so now we have a PGT. Next slide. ST Web browser C

CAS 2.0: Proxy CAS NetID PGTURL PT S PT S PGT Back-end application Web
Data PT Suppose the web application (e.g. Sakai) wants to proxy authentication to some back-end application or service (e.g., the IMAP server). We need a service identifier string for the back-end application. This can be an arbitrary string. In the case of accessing URLs, it is by convention the URL being accessed. But the only thing that matters is that proxier and proxy recipient agree on this string. The proxying web application presents to CAS its [PGT] and this service identifier [S] in order to obtain a [PT] targetted to the back-end service. The proxying web application then presents this [PT] to the back-end application on its request to that back-end application for data. The back-end application validates the [PT], [S] pair with CAS and receives a validation response including the [NetID] and the [PGTURL] to which the PGT was sent when the proxying web application validated its service ticket. That is, the validation response includes the whole chain of authenticated entities leading to the PT that the back-end application is validating. The back-end application scrutinizes this proxy chain and decides what [Data] to return (based on what service is asking and what user they are asking on behalf of). Web browser

Portal authentication
Portals need to authenticate users To provide customized content To restrict portal-accessible resources Portals also need access to third-party resources “as the user” “n-tier” authentication Single sign-on

Aggregating content → Aggregating authentication
After Before Portals push the need for single sign on Aggregating content where different credentials are needed for every application shines a bright light on an unpleasant situation Bringing all the apps together doesn’t solve it but it makes a solution critical

What we will cover How does uPortal authenticate users in the first place? What is the N-tier authentication problem? How does the Yale’s model, called CAS, (Central Authentication Service) solve the problem?

uPortal’s pluggable security-context mechanism
Authentication support in uPortal manifested through ISecurityContext: Key functions: Accept IPrincipal Accept IOpaqueCredentials Authenticate user Return true/false (and optionally more)

uPortal’s authentication infrastructure: advantages
Flexibility Adapts to nearly any back-end campus authentication solution – e.g., Kerberos (4, 5) LDAP “authentication” Unix password file (small-scale) Server-based authentication (“trust”) Supports “chaining” providers to establish more than one context.

ChainingSecurityContext
Allows for a chain or a tree of providers to be called Originally envisioned as acquiring multiple credentials at sign in For Example: A database connection or an LDAP initial context or Kerberos TGT Has not turned out to be the enabling component for single sign on For example a system in which different security domains use the same password. Authentication could take place in both domains at the time the user logs in. Credentials such as TGT, database connection would be cached for channel to use but not the pass phrase. This is not really what is needed it turns out. Some places have the problem of multiple principals and passwords. This must be solved separately – no magic here. We don’t really want to “logon” to all the possible services a portal user may use at the beginning – really we want to acquire these resources at the time they are requested.

UnionSecurityContext
Simple Provider (password) CAS Union Provider Can sit at the top of the tree of chaining providers and present isAuthenticated status and credentials of first provider in the chain to succeed Portal property determines whether to continue

N-tier authentication
Channel Portal So far we have covered how we authenticate users into the portal but how do we convince back end applications and services that the user is authentic?

uPortal’s authentication infrastructure: disadvantages
Limitations Provides unified authentication “gate,” but no extra portal-specific functionality. No single sign-on. Just a model—does little work itself. But… can be wrenched to cache passwords: Accepts university security model; doesn’t automatically adapt to it itself. You still need to provide front-end, etc. IOpaqueCredentials NotSoOpaqueCredentials String getCredentials(); (Not particularly secure)

Caching Security Provider
A way to replay passwords by giving channels access to them Not the best idea May expose password to insecure use by channels Participating applications have less security than before If the portal is compromised users’ primary credentials are compromised If storing passwords can accomplish single sign-on, why not do so? uPortal instance/server must be trusted. To accept password To store it securely All network links must be secured. Each individual channel must be trusted. All web applications must be trusted. Password confers access “forever.” Overall, user loses control of authentication granularity.

Password caching Password- protected service Portal Channel PW PW PW
Just one of these needs to be compromised, to attack user “forever”! Channel PW Password- protected service PW PW

Given the drawbacks of caching and re-using passwords, what’s a better approach?
How can a web based Single Sign on System really work?

Web-based single sign-on
Why is this problem different from existing single sign-on systems? Limited client support Yale’s model is called CAS (Central Authentication Service). Model based (loosely) on Kerberos. “100% Pure Java” Pluggable back-end Available through JA-SIG Clearinghouse Thank you to Shawn Bayern Other models: Liberty, Pubcookie (Washington), MACE WebISO, Passport

CAS in a nutshell Authenticates via password (once) Determines
validity of user’s claimed authentication Authenticates without sending password 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 actually works S T Web resource CAS S S T Web browser C

Back to the N-tier problem
uPortal can authenticate users securely with CAS. But it does not have first-hand knowledge of users’ credentials. This is a good thing . . . Except that uPortal can’t impersonate the user in order to acquire secure data for the user.

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.

Proxiable credentials illustrated
IMAP server CAS PAM module S T IMP CAS PGT PT PGT PT PT Username Identity of web resource

CAS Security Provider Uses CAS for primary authentication
Use CAS ProxyTicketReceptor servlet to receive PGT to be redeemed later Exposes public method to channels to get a Proxy Service Ticket for a particular service Back end system must be configured to validate and accept proxy credentials from uPortal

uPortal with CAS Provider
Channel resource uPortal with CAS Provider PT PT Channel PT Username Identity of proxy (portal) getCasServiceToken CAS S T CAS Security Context PT PGT IOU getProxyTicket(pgtIou,service) PGT CAS Ticket Receptor Servlet PT PGT PT

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

CAS at Yale Used by systems in support of students and administrators
Used occasionally by unprivileged students Mostly Java and Perl; some ASP, PHP Apache module used widely Proxy authentication: incipient deployment PAM module to be used with servers uPortal deployment using proxy to LMS and

Extending CAS 3 Clustering Failover Attributes Certificates Events
Service Restrictions Web Services

Clustering Ticket Registry Session Management Distributed Ticket Store
Shared Ticket Store Session Management Sticky sessions Remove sessions entirely

Failover Not handled by CAS directly Content Switch CAS-spare

Attributes CAS allows attachment of attributes to:
Principal Authentication object Attributes are available to payload Customize payload to return attributes you need

Automatically Presented Credentials
Credentials such as… Certificates Modify login web flow to place check for credentials before

Events Publishes events: EventListener captures published events
Authentication Ticket creation, destruction, etc. EventListener captures published events Custom EventHandler to handle events

Service Restrictions Example in code repository
Use to protect CAS from unauthorized services Uses whitelist

Web Services Designed that layers are separated
Expose layer as multiple types of web services Hessian Burlap SOAP HttpInvoker

Future CAS Extensions SAML response Single Sign Out
Administration Summary Screens Expose more configuration options via JMX What would you like to see?

Central Authentication Service

Similar presentations

Presentation on theme: "Central Authentication Service"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Central Authentication Service

Similar presentations

Presentation on theme: "Central Authentication Service"— Presentation transcript:

Similar presentations

About project

Feedback