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

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

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

6. 66 66 Cal Poly 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.

7. Motivation

8. 88 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 Motivation

9. 99  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 Motivation (con’t)

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

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

12. Implementation

13. 13 System Overview

14. 14

15. 15

16. 16  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 uPortal - Cal Poly Enterprise Portal

17. 17 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 CAS – Yale Central Authentication Service

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

19. 19  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) LDAP

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

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

22. 22 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; PeopleSoft - Implementation

23. 23 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") // into PSFT username ("jdoe") return line2;.substring(0, line2.indexOf('@')).toUpperCase(); }} 23 PSCASClient.java

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

25. 25 Set Exec Auth Fail PeopleCode

26. 26  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 PeopleSoft - Implementation

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

28. 28 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 Enterprise Portal Integration

29. 29

30. 30

31. Environment

32. 32  E xecutive 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 Non Technical Challenges

33. 33 Technical Specifications

34. 34  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 Technical Specifications

35. 35  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 Technical Specifications

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

37. 37  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 Unique users per DAY  Maximum: 14,000  Average: 5,700  Single Sign-on Concurrent users of the Portal: High: 2,800 Statistics on Usage

38. 38  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 Statistics on Usage

39. 39 Support

40. 40 Organization of Ext Auth Support

41. 41  T echnology 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 Support

42. 42  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 Consortium of Internet2, EDUCAUSE, and SURA  Other campuses Academic Outreach

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

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

45. 45  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 Lessons Learned

46. 46  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 References

47. QUESTIONS?  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  Terry Vahey Technical Lead tvahey@calpoly.edu  Greg Weir PeopleSoft Developer gweir@calpoly.edu http://www.calpoly.edu/~cms/ExtAuthentication/index.html

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