eAuthentication from a Portal perspective

1. eAuthentication from aPortal perspective "You can spend your life searching for a Grail, but I just bought a very nice set of cups at Pottery Barn"

2. What the Admin Wanted Students P O R T A L Financial Aid Deans Faculty Staff Courses HR Parents PR Applicants StudentOrganizations Library Public Alums

3. Client-Only

4. Publish Only

5. My Definition of "Portal" • Information Broker • User specifies preferences • interests, priorities, layout, filters, ... • Publishers provide content • RSS, XML, portlets, ... • Portal aggregates, filters, formats, organizes, and presents under user control with Administration overrides

6. Why Build, Why not Buy C O U R S E S History Math Economics Biology Philosophy English Physics A Portal is the Network version of what Universities have always done, so we better learn how to do this right or we will become obsolete.

7. Ground Zero in the Authentication Train Wreck • Users may have different methods of authentication • Data sources may have different methods of authorization • We can change some information sources, but at some point we have to accommodate legacy systems or lose their content.

8. What is a Principal? • In practice, after authentication a user is associated with an "Account" on some system • Kerberos, AD, mail, DBMS, Bank, Credit Card • Systems may associatively link their account ID with a foreign ID • ("click here to have us email your password" links the local account to an E-Mail account)

9. People have multiple identity accounts • Faculty member at Yale • Undergrad Alum at Penn State • PhD at Princeton • Parent of student at Boston College • Researcher on ... project The Alumni don't typically authenticate through thesame system as current students.Never will be a universal ID card.

10. The Perfect is the Enemy of the Better • Passwords should be • Too large and obscure to remember • Different for every service • Not written down anywhere • Before using certificates • Spend 5 years looking for a root CA • Run the policy through 8 committees and the General Council's office.

11. While we spend 5 years arguing about best practices • The user's password is "doom3" • The password is written on post-it notes stuck to the side of the keyboard • He uses the same password to logon to porn sites in Bulgaria, and they sell passwords for $5/thousand to Muhammad Naeem Noor Khan in Pakistan

12. No Good Single Answer • Kerberos - good for logons, but not supported by Browsers • Certificates - PKI easy to build, impossible to plan, supported mostly by Browsers and Windows SmartKey • What about IMAP, Oracle Applications, offsite partners, ...

13. Yale CAS • Pretty Good Authentication for Web SSO • Send existing institutional password once over SSL to a well known CAS server • CAS randomly generates, short term, single use, service-specific "passwords", appends them to the URL and redirects the Browser back to the service. • Open source, written in Java

14. User Needs LogonService Redirects to CAS CAS Browser Server

15. HTTPS secure logon to CAS

16. CAS appends "ticket=" and redirects back to service CAS Browser Server

17. Using backchannel HTTPS sessionserver trades ticket in for Netid CAS Browser Server

18. Advantages • Password sent once over SSL to one well known secure server • Any backend: K5, LDAP, JAF, ... • Redirects transparent after login • CAS talks to any Resource anywhere • Ticket is worthless after use, so http: is OK

19. CAS-ify an Application • Filters for Apache, IIS, Servlet • Use PAM to validate "password" that is really a ticket to "password store" that is really CAS

20. CAS Proxy Ticket CAS Browser Portal

21. Portal uses Proxy Ticket to get Service Ticket for third-tier Service CAS Browser E-Mail Portal

22. Service presents ticket to CAS, gets Netid CAS Browser E-Mail Portal

23. Proxy Rules • CAS will authenticate to any service, but you have to be configured to be a proxy. • Proxy tickets vended over SSL (proxy verified by certificate) • CAS and proxy must share a CA, but it can be homebrew

24. Nothing Special • There are other Web signon systems and they all operate in the same space • CAS is simple, open, and deployed, but follows no particular standard • Raw CAS is impractical across institutions • Other places will make other choices Therefore, Shibboleth

25. Shibboleth 0 CAS Resource Browser UCLA Yale User logs into CAS, tries to access remote Resource

26. Shibboleth 1 CAS Resource IDProvider Browser AuthenticationAssertionConsumer SAML Authentication Assertion Browser is redirected to ID Provider at login site. ID provider uses local signon (CAS) to verify netid, then vends a generated handle.

27. Shibboleth 2 Resource IDProvider Browser more Shibboleth AttributeAuthority SAML Attribute Assertion Service Provider uses Authentication to query Attributes of user from Attribute Authority at user's login site

28. Shibboleth 3 Resource Browser Attributes more Shibboleth Meanwhile, Browser was redirected back to Resource. Shibboleth now provides attributes to make access decision.

29. Why Shibboleth? • I log on to Yale. Yale knows me. • Yale says, "This is a staff member at Yale ITS". • UCLA checks the signature/key and finds it is an authentic assertion of Yale University. • UCLA then passes this info to UCLA services, who only have to trust what they get from UCLA. • UCLA would reject a message from Yale University asserting that I am "a staff member at UCLA ITS" as out of scope.

30. What is Shibboleth • An application of SAML (HTTP-SOAP) • Provides practical requirements missing from SAML standard (Where is Yale? Do I trust this signature?) • Still not complete • Requires external local authentication (K5, LDAP, CAS) • Requires external local attributes (LDAP, database, ...)

31. OSI is dead, long live IP • Use Shibboleth to prove credentials, get "guest account" on foreign system through front-end admin tool. • Use Shibboleth to get new certificate or have existing certificate countersigned, or get a broadly scoped Cookie. • Portal can navigate through the sequence of steps

32. What does this suggest about Certificates and Keys? • CAS: A service to generate short term, single purpose certificates so transient that you don't have worry about them • Shibboleth: If UCLA gets a Certificate from Yale, verify it through institutional trust, check that its assertions are Yale-local, then countersign it with a UCLA signature. UCLA hosts don't have to know the Yale CA.

33. Suggestions • Chill out • Deploy a solution for next year, not the next 20 years • If the real world is too inflexible, maybe it is you who are too demanding • After beating your head against a brick wall, consider rethinking your strategy

34. Myth: The Root CA • Web Servers need a certificate with a root CA known to the Browser, or there will be an error message • Otherwise, you really need to know and trust the specific CA issuing the certificate, with or without its root. • If UBL came to Yale, we might issue a certificate saying he is "UBL at Yale", but that doesn't mean you should trust him.

35. In most versions of the legend, the quest for the Grail ended badly. • Cross-institutional authentication can only occur with configurations of Trust (certificate databases) and Federations to maintain and distribute them • We can't make attributes fully public (LDAP) but can distribute on a need-to-know, user request basis (Shibboleth) • Acquiring access and accessing the resource may be separate transactions