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"

What the Admin Wanted

Students

FacultyStaff

ParentsApplicants

Public

PORTAL

Financial Aid

Deans

Courses

HRPR

StudentOrganizations

Library

Alums

Client-Only

Publish Only

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

COURSES

History

Math

Economics

BiologyPhilosophy

EnglishPhysics

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

• 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.

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 "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

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, ...

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 LogonService Redirects to CAS

Browser

Server

CAS

HTTPS secure logon to CAS

CAS appends "ticket=" and redirects back to service

Browser

Server

CAS

Using backchannel HTTPS sessionserver trades ticket in for Netid

Browser

Server

CAS

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

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

Browser

Portal

CAS

Portal uses Proxy Ticket to get Service Ticket for third-tier Service

Browser

Portal

CAS

E-Mail

Service presents ticket to CAS, gets Netid

Browser

Portal

CAS

E-Mail

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

User logs into CAS, tries to access remote Resource

Yale UCLA

Shibboleth 1

CAS

Resource

Browser

IDProvider

AuthenticationAssertionConsumer

SAML Authentication Assertion

Browser is redirected to ID Provider at login site. ID provider useslocal signon (CAS) to verify netid, then vends a generated handle.

Shibboleth 2

Resource

Browser

IDProvider

moreShibbolethAttribute

Authority

SAML Attribute Assertion

Service Provider uses Authentication to query Attributes of user from Attribute Authority at user's login site

Shibboleth 3

Resource

Browser

moreShibboleth

Attributes

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

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.

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, ...)

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-to-know, user request basis (Shibboleth)

• Acquiring access and accessing the resource may be separate transactions