External Authentication at Cal Poly ( Single Sign-on is not a Fantasy)

1. External Authentication at Cal Poly(Single Sign-on is not a Fantasy) Session #10184 March 22, 2005 HEUG 2005 Conference Las Vegas, Nevada

2. San Luis Obispo, CA Information Technology Services Darren Kraker Terry Vahey

3. Overview • Case study: Cal Poly’s implementation of external authentication for PeopleSoft Human Resources and Financials • Motivation: Easier for users, improved security administration • Tools: • Yale University Central Authentication Service • JA-SIG uPortal • LDAP using Oracle Internet Directory • PeopleSoft 8.0 & 8.4

4. Agenda/Contents • Motivation • Implementation • Support • Lessons learned • Next steps • Questions

5. Cal Poly – Who are we? • Part of the California State University (CSU) system • CSU is the largest four-year university in the nation. • CSUcomprised of 23 campuses throughout California • CSU enrolls approx 409,000 students • CSU students taught by approx 22,000 faculty 5 5

6. Cal Poly – Who are we? • San Luis Obispo • 100 Years Old • 20,000 Students • Polytechnic University Engineering, Agriculture, Architecture, Science • “Learn by Doing”: technical and professional curricula with arts and humanities. 6 6

7. Motivation

8. Motivation Why Enterprise Single Sign-on & Portal? • Easier on the users • One username and password • Single login interaction / operation • Integrated with other Web applications in one Enterprise Portal

9. Motivation (con’t) • Improved Security Administration • Simplify account setup (provisioning) • Passwords and authentication security consistently enforced and in one location • Simplified change management, auditing • For Web apps, do it once, do it right

10. Considerations • Vendor neutrality • Integration with current and future vendor offerings • Reusable by other web apps • Higher education best practices • Highly available • Focus on web authentication

11. Limitations of Web Single Sign-on • Primarily available for Web applications • There is no standard in this space • Requires custom integration with each application • Additional time required to implement

12. Implementation

13. System Overview

16. uPortal - Cal Poly Enterprise Portal • uPortal is an open-standard effort using Java, XML, JSP and J2EE • Began using uPortal Fall 2001 as our campus portal • Integrate disparate campus systems in one location • Aggregate content from campus constituents

17. CAS – Yale Central Authentication Service We want Single Sign-on but how? • Evaluated Pubcookie, WebAuth . . . • Simple to install and configure • Variety clients available (Apache module, PHP, Java, etc) for integration • Delivered implementation with uPortal • Application can authenticate without the users credentials directly

18. 3 Web Login Service recognizes user session 7 Username provided to application 6Application validates ticket 4 Login Service provides ticket 1 User requests access 2Browser redirected to Login Service 5Ticket provided to application 9 User gets access Web Login Service CASAuthentication Flow User interaction No user interaction User Web Application 8 Application decides if user is authorized

19. LDAP • Oracle Internet Directory, 9i • Currently single source of username and password • Allows non-web based apps to authenticate • Contains data from HR, Foundation, ASI, Student Info Systems, … • Was in place before CAS (2001)

20. PeopleSoft • Making PeopleSoft use a central authentication service • Evaluate known solutions • Integration with CAS

21. PeopleSoft - Implementation Accept a ticket and then validate it • PeopleSoft accepts CAS ticket parameter as part of login • PeopleCode calls Java client • CAS java client performs the CAS validation

22. PeopleSoft - Implementation Function VALIDATE_TICKET() /* rmatteso@calpoly.edu 20030122 Trusted Authentication Impl */ If %PSAuthResult = False Then &validator = GetJavaClass("PSCASClient"); /* retrieve fullUrl and ticket value from HTTP request */ &fullUrl = %Request.FullURI | "?" | %Request.QueryString; &ticket = %Request.GetParameter("ticket"); If &ticket <> "" Then /* have a ticket, load CAS client class and attempt to validate */ &cas_result = &validator.validate(&fullUrl, &ticket); If &cas_result <> "" Then /* ResultDocument (3rd parm) seems to be ignored by front end */ SetAuthenticationResult( True, &cas_result, "", False); &authMethod = "SLO"; Return; End-If; /* got username back from CAS */ End-If; /* got ticket */ End-If; /* user not yet authenticated */ End-Function;

23. PSCASClient.java URL u = new URL( validateURL + "?ticket=" + ticket + "&service=" + service); BufferedReader in = new BufferedReader( new InputStreamReader(u.openStream())); if (in == null){ return null; }else { String line1 = in.readLine(); String line2 = in.readLine(); if (line1.equals("no")){ return null; }else{ // make fully qualified username ("jdoe@calpoly.edu") // into PSFT username ("jdoe") return line2;.substring(0, line2.indexOf('@')).toUpperCase(); } } 23

24. PeopleSoft - Implementation • Configure SLO_AUTH hook in PeopleSoft Sign-on Page (Exec Auth Fail)

25. Set Exec Auth Fail PeopleCode

26. PeopleSoft - Implementation • Customize HTML files now that original sign-on page is obsolete • index.html • Logout_page.html (new) • Signin_alternate (new) • Signon.html • signonError.html (new) • Cookiesrequired.html • Modify configuration.properties to point to new HTML files • Install CAS client jar, class files

27. Issues It’s never that easy . . . • Service URL we use for CAS had to contain userid/pwd parameter • PeopleSoft cookies • After PTools upgrade (2003) HTTP GET no longer worked, POST required

28. Enterprise Portal Integration The next step . . . deep linking • More direct and intuitive method for accessing services • Add embedded PeopleSoft content within an IFrame using nested URL • Similar solution with Oracle Collaboration Suite

31. Environment

32. Non Technical Challenges • Executive mgmt buy-in, enterprise wide • Data providers • Information security officer, Registrar • Skepticism • Too hard to implement • Don’t see the value • PeopleSoft application • Fear of losing control of authorization

33. Technical Specifications

34. Technical Specifications • CAS servers • Central Authentication Server 2.0 • Servers: Sun Netra T1 • 500 mhz, 1 GB RAM • Solaris 9 • Three servers high availability • Cisco switches provide failover

35. Technical Specifications • LDAP servers • Oracle Internet Directory: 9.2.0.6 • Servers: Sun Netra T1 • 500 mhz, 1 GB RAM • Solaris 9 • Three servers for high availability • Cisco hardware provides load balancing and failover

36. Technical Specifications • uPortal server • uPortal 2.1.4 • One server: Sun E450 • 4 - 400 mhz, 4 GB RAM • Solaris 9

37. Statistics on Usage • PeopleSoft Applications: • HR total accounts: 2,500 (admin accounts: 700) • Concurrent users average: 22 (high 75) • Finance total admin accounts: 700 • Concurrent users average: 23 (high 95) • Single Sign-on Unique Users per month: • Approx: 12,000 - 28,000 • Average: 20,000 (including summer quarters) • Single Sign-on Uniqueusersper DAY • Maximum: 14,000 • Average: 5,700   • Single Sign-on Concurrent users of the Portal: High: 2,800

38. Statistics on Usage • Single clicks to HR PRD and FS PRD per month • 2,200 – 6,100 • Average: 4,200 (including summer quarters) • Single Sign-on Outages • Unplanned: Less than 1/2 hour per month • Planned: • 4 hours/month • Updates, new application rollouts • Users CAN authenticate to PS and other applications

39. Support

40. Organization of Ext AuthSupport

41. Support • Technology is very low maintenance • CAS Production updates: ~ 3 hrs month • Reviewing logs, usage patterns: ~ 4 hrs month • Troubleshooting: • Password management – in a single location now • Made passwords more secure • Plan: Upgrade CAS code this year

42. Academic Outreach • NSF funded grant project • Helping member campuses • directory services and CAS • PeopleSoft and Oracle integration • Funded by the NSF Middleware Initative through the NMI-EDIT Consortiumof Internet2, EDUCAUSE, and SURA • Other campuses

43. Next Steps • Implement Student Administration (SSO already in place with HR) • Upgrade CAS • Integration with PeopleSoft version 8.9 • Add redundancy for uPortal • Alternate authentication methods

44. Our Wish List • PeopleSoft Applications and PeopleTools Support of Standards • Make the application’s content available via: • WSRP (as producer) • JSR 168

45. Lessons Learned • Technical lessons • Involve campus Information Security Officer (ISO), CIO at the beginning • “It’s all about the data” • Ongoing process • Department’s understanding • Work with application programmers for integration and testing challenges

46. References • CAS http://www.yale.edu/tp/cas/ • JA-SIG http://www.ja-sig.org/ • uPortal http://www.uportal.org/ • PeopleBooks • Cal Poly’s: PPT, PeopleSoft Single Sign-on Guides http://www.calpoly.edu/~cms/ExtAuthentication/index.html

47. QUESTIONS? • Terry Vahey Technical Lead tvahey@calpoly.edu • Greg Weir PeopleSoft Developer gweir@calpoly.edu • Darren Kraker Software Engineer dkraker@calpoly.edu • Ryan Matteson Web Architect and Info Security Manager rmatteso@calpoly.edu • Ken Sperow Software Engineer ksperow@calpoly.edu http://www.calpoly.edu/~cms/ExtAuthentication/index.html

48. This presentation and all HEUG 2005 presentations are available for download from HEUG Onlinehttp://heug.org