- Количество слайдов: 35
e. Authentication from a Portal perspective "You can spend your life searching for a Grail, but I just bought a very nice set of cups at Pottery Barn"
What the Admin Wanted Students Financial Aid Faculty Parents Public Staff Applicants P O R T A L Deans Courses HR PR Library Alums Student Organizations
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
Why Build, Why not Buy History C O U R S E S 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.
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.
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)
People have multiple identity accounts • • • Faculty member at Yale Undergrad Alum at Penn State Ph. D at Princeton Parent of student at Boston College Researcher on. . . project The Alumni don't typically authenticate through the same system as current students. Never will be a universal ID card.
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.
While we spend 5 years arguing about best practices • The user's password is "doom 3" • 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
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 Smart. Key • What about IMAP, Oracle Applications, offsite partners, . . .
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
User Needs Logon Service Redirects to CAS Browser Server
HTTPS secure logon to CAS
CAS appends "ticket=" and redirects back to service CAS Browser Server
Using backchannel HTTPS session server trades ticket in for Netid CAS Browser Server
Advantages • Password sent once over SSL to one well known secure server • Any backend: K 5, LDAP, JAF, . . . • Redirects transparent after login • CAS talks to any Resource anywhere • Ticket is worthless after use, so http: is OK
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
CAS Proxy Ticket CAS Browser Portal
Portal uses Proxy Ticket to get Service Ticket for third-tier Service CAS Browser E-Mail Portal
Service presents ticket to CAS, gets Netid CAS Browser E-Mail Portal
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
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
Shibboleth 0 CAS Resource Browser Yale UCLA User logs into CAS, tries to access remote Resource
Shibboleth 1 CAS Browser ID Provider SAML Authentication Assertion Resource Authentication Assertion Consumer Browser is redirected to ID Provider at login site. ID provider uses local signon (CAS) to verify netid, then vends a generated handle.
Shibboleth 2 Browser ID Provider Attribute Authority Resource more Shibboleth SAML Attribute Assertion Service Provider uses Authentication to query Attributes of user from Attribute Authority at user's login site
Shibboleth 3 Resource Browser Attributes more Shibboleth Meanwhile, Browser was redirected back to Resource. Shibboleth now provides attributes to make access decision.
Why Shibboleth? • I log on to 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.
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 (K 5, LDAP, CAS) – Requires external local attributes (LDAP, database, . . . )
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
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.
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
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.
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-toknow, user request basis (Shibboleth) • Acquiring access and accessing the resource may be separate transactions