uPortal Security and CAS

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

2. 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

3. Before After Aggregating content → Aggregating authentication

4. 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?

5. 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)

6. 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.

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

8. Union Provider Simple Provider (password) CAS Provider UnionSecurityContext • 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

9. N-tier authentication Channel Portal

10. 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: IOpaqueCredentials NotSoOpaqueCredentials String getCredentials(); (Not particularly secure)

11. 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

12. Password caching Password- protected service Portal Channel PW PW PW PW Password- protected service Channel PW PW PW PW Channel PW Password- protected service PW PW

13. 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?

14. 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

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

16. 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)

17. How CAS actually works S T Web resource CAS S S T Web browser C

18. 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.

19. 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.

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

21. 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

22. uPortal withCAS 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

23. 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.

24. uPortal at Yale A very brief demo

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