uPortal Security and CAS Susan Bramhall ITS Technology & Planning Yale University

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 Before After 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 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 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.

uPortal at Yale A very brief demo

Finally Some words from others about experience with CAS in uPortal Questions? URL for CAS distribution and uPortal provider: http://www.yale.edu/tp/cas/