uPortal Authentication Options: Design and Application

1. uPortal Authentication Options: Design and Application Shawn Bayern Research programmer, Yale University Author, Web Development with JavaServer Pages JSTL implementation lead (JCP, Apache)

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. N-tier authentication Portal

5. uPortal and authentication • Three key questions to answer today: • How does uPortal authenticate users? Will its support work at your school? • What does a sample single sign-on system look like? • How can uPortal interface with campus-wide single sign-on?

6. Question 1 How does uPortal authenticate users in the first place?

7. uPortal’s pluggable security-context mechanism • Authentication support in uPortal manifested through three key interfaces: • ISecurityContext • Instance of authentication system (“engine”) • IPrincipal • Context-specific user • IOpaqueCredentials • Context-specific credential (e.g., password) • Kept safe

8. ISecurityContext • Interface representing single-use authentication engine. • Key function: • Accept IPrincipal • Accept IOpaqueCredentials • Authenticate user • Return true/false (and optionally more)

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

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. Password caching: Drawbacks • 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.

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. Question 2 Given the drawbacks of caching and re-using passwords, what’s a better approach? How can a true “single sign-on” system work on the web?

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 • 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. How CAS actually works S T Web resource CAS S S T Web browser C

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

18. CAS characteristics • Requires no service pre-registration • Services are not privileged; may only compromise themselves. • Supports but does not require cookies • Uses but does not require JavaScript • Usable by multiple languages, systems (Java, C, JSP tags, ASP, Perl) • Free and open-source • Implemented using Java servlets

19. CAS at Yale • Used by systems in support of students and staff. • Used occasionally by unprivileged students. • Mostly Java, Perl. Some ASP. • Apache module becoming widely used • C implementation of CAS “client” within Apache server • Server-wide authentication • AuthType CAS → REMOTE_USER

20. 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 (Apache Server) • May depend on particular institutional characteristics—e.g., • Network topology • Service hosting on institutionally managed web servers

21. Question 3 What is uPortal’s role in a campus-wide single sign-on framework?

22. CAS and portals • Using CAS as an example of campus-wide single sign-on service… • How to use single sign-on within portal? • Unlike many applications, a portal is not the source of all the information it vends. • “n-tier” authentication problem • How to avoid several “bad things”? • Password caching • Excessive trust of portal • Modifying legacy systems • Balancing objectives

23. Integration strategies • Option 1: insert portal into initial CAS login • Portal receives password, then redirects the user to CAS and coerces the browser to re-send the password • User ends up with CAS ticket. • Portal ends up with CAS ticket too • Password caching isn’t precluded, but it’s not necessary either.

24. Integration strategies “CAS-ified” service Portal Password Channel “CAS-ified” service Channel CAS TGT Channel “CAS-ified” service

25. Integration strategies S T Portal’s “CAS client” CAS S S T Web browser C Portal’s initial page

26. Integration strategies • Option 2: CAS services can be made aware of uPortal • Services simply use CAS, but acknowledge a URL “owned” by uPortal. • Advantages: uPortal need not be trusted or especially secure. • Drawbacks: services need to be modified and made portal-aware. • If you are already allowed to do this, you’re not facing difficult hurdles anyway!

27. Integration strategies CAS Service Portal Channel CAS sees a single “service.” However, this “service” consists of the portal (more specifically, a channel), and an outside CAS-ified service. Modified “CAS-ified” service

28. Integration strategies Back-end service S T S T Portal CAS S S T Web browser C

29. Integration strategies • Option 3: use Kerberos 5 (or similar “traditional” single sign-on system) for all network services • CAS becomes web-based “Kerberos user agent” • User authenticates to agent. • Agent manages tickets, proxying for the user. • Drawback: requires substantial planning, effort, scope

30. Integration strategies Web resource CAS Non-web resource Web resource K5 realm C Web browser Web resource

31. CAS future • Support application-driven “reauthentication” requirement • Instead of more complex system of “security rings” or “application groups”

32. Summary • uPortal has two uses for authentication: • Customizing its own presentation. • Accessing secure resources • Caching passwords is generally a security risk. • Models like CAS let you avoid caching passwords.

33. URLs • CAS distribution • JA-SIG Clearinghouse • http://www.yale.edu/tp/cas/ • Source distribution • uPortal integration example (option 1) • Design paper • License information • My email address • shawn.bayern@yale.edu

34. Q&A • Alternative single sign-on systems? • CAS implementation questions? • uPortal integration ideas? • uPortal authentication subsystem questions?