External Authentication at Cal Poly Single Sign-on is

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

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

Overview Ø Case study: Cal Poly’s implementation of external authentication for People. Soft Human Resources and Financials Ø Motivation: Easier for users, improved security administration Ø Tools: § Yale University Central Authentication Service § JA-SIG u. Portal § LDAP using Oracle Internet Directory § People. Soft 8. 0 & 8. 4 3

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

Cal Poly – Who are we? Cal Poly Ø 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 5 5

Cal Poly – Who are we? Cal Poly Ø 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

Motivation 7

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 8

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 9

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 10

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 11

Implementation 12

System Overview 13

14

15

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

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

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

LDAP Ø Oracle Internet Directory, 9 i Ø 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) 19

People. Soft Ø Making People. Soft use a central authentication service Ø Evaluate known solutions Ø Integration with CAS 20

People. Soft - Implementation Accept a ticket and then validate it Ø People. Soft accepts CAS ticket parameter as part of login Ø People. Code calls Java client Ø CAS java client performs the CAS validation 21

People. Soft - Implementation Function VALIDATE_TICKET() /* rmatteso@calpoly. edu 20030122 Trusted Authentication Impl */ If %PSAuth. Result = False Then &validator = Get. Java. Class("PSCASClient"); /* retrieve full. Url and ticket value from HTTP request */ &full. Url = %Request. Full. URI | "? " | %Request. Query. String; &ticket = %Request. Get. Parameter("ticket"); If &ticket <> "" Then /* have a ticket, load CAS client class and attempt to validate */ &cas_result = &validator. validate(&full. Url, &ticket); If &cas_result <> "" Then /* Result. Document (3 rd parm) seems to be ignored by front end */ Set. Authentication. Result( True, &cas_result, "", False); &auth. Method = "SLO"; Return; End-If; /* got username back from CAS */ End-If; /* got ticket */ End-If; /* user not yet authenticated */ End-Function; 22

PSCASClient. java URL u = new URL( validate. URL + "? ticket=" + ticket + "&service=" + service); Buffered. Reader in = new Buffered. Reader( new Input. Stream. Reader(u. open. Stream())); if (in == null){ return null; }else { String line 1 = in. read. Line(); String line 2 = in. read. Line(); if (line 1. equals("no")){ return null; }else{ // make fully qualified username ("jdoe@calpoly. edu") // into PSFT username ("jdoe") return line 2; . substring(0, line 2. index. Of('@')). to. Upper. Case(); } } 23 23

People. Soft - Implementation Ø Configure SLO_AUTH hook in People. Soft Sign-on Page (Exec Auth Fail) 24

Set Exec Auth Fail People. Code 25

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

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

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

29

30

Environment 31

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 Ø People. Soft application § Fear of losing control of authorization 32

Technical Specifications 33

Technical Specifications Ø CAS servers § Central Authentication Server 2. 0 § Servers: Sun Netra T 1 § 500 mhz, 1 GB RAM § Solaris 9 Ø Three servers high availability Ø Cisco switches provide failover 34

Technical Specifications Ø LDAP servers § Oracle Internet Directory: 9. 2. 0. 6 § Servers: Sun Netra T 1 § 500 mhz, 1 GB RAM § Solaris 9 Ø Three servers for high availability Ø Cisco hardware provides load balancing and failover 35

Technical Specifications Ø u. Portal server § u. Portal 2. 1. 4 § One server: Sun E 450 § 4 - 400 mhz, 4 GB RAM § Solaris 9 36

Statistics on Usage Ø People. Soft 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 37

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 38

Support 39

Organization of Ext Auth Support 40

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 41

Academic Outreach Ø NSF funded grant project § Helping member campuses § directory services and CAS § People. Soft and Oracle integration §Funded by the NSF Middleware Initative through the NMI-EDIT Consortium of Internet 2, EDUCAUSE, and SURA Ø Other campuses 42

Next Steps Ø Implement Student Administration (SSO already in place with HR) Ø Upgrade CAS Ø Integration with People. Soft version 8. 9 Ø Add redundancy for u. Portal Ø Alternate authentication methods 43

Our Wish List Ø People. Soft Applications and People. Tools Support of Standards Ø Make the application’s content available via: § WSRP (as producer) § JSR 168 44

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 45

References Ø CAS http: //www. yale. edu/tp/cas/ Ø JA-SIG http: //www. ja-sig. org/ Ø u. Portal http: //www. uportal. org/ Ø People. Books Ø Cal Poly’s: PPT, People. Soft Single Sign-on Guides http: //www. calpoly. edu/~cms/Ext. Authentication/index. html 46

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

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