January 9, 2002 Internet2 WebISO Project RL "Bob" Morgan, University of Washington

Topics How it came to be Project status WebISO defined Project goals Architecture/Interface

How it came to be Shibboleth project assumption: •every campus has intra-campus web authentication •startling discovery: not true The MACE way: do something about it •brief search for likely sharable implementations •U of Washington's "pubcookie" chosen as starting point •project started to make "appropriate progress" •now looking at architectural issues, other implementations

WebISO project status It's live: •web: • 40+ on list •active work on refining project goals, gathering requirements, describing architecture Pubcookie package •code freely available, 1 non-UW deployment (CMU), several pending; BSD-style license •CMU, Hawaii contributions incorporated •support from Mellon Foundation for further UW work

WebISO defined Organizational web-based sign-on system Typically includes: •single sign-on (only "type something" once to access multiple target web sites) •use of standard authentication backend (LDAP, Kerberos, NIS, NT, etc) •keep passwords away from application web servers (only sent to "weblogin" server) "Most reinvented technology of the 1990s"

WebISO components Module for application webservers •check for authentication info on request, if not found redirect browser to weblogin server •interpret authentication info, pass to web application Weblogin server •accept redirected request, prompt for userid/password (or other authn method) •return browser to target webserver, with authn info Message format for appserver weblogin

The pubcookie story "Just another webiso" •written in C •Apache, MS-IIS target web servers •Apache-based weblogin •Kerberos 5 backend built-in, others possible •in production since 1999 •web-based documentation •signed/encrypted messages, sent using cookies •works with almost all browsers

Pubcookie planned improvements •better docs, clearer installation procedures •more authentication backends, pluggable •X.509 client cert authn, Kerberos client authn •variable-length SSO session support •per-user, per-server settings •"blinded" userids •easier/automatic key management •authn tokens in URLs (cross-DNS-domains) •robustness, quality assurance, modularity... •many require rethinking, justification, threat model

Project goals Not just pubcookie enhancement/support •e.g., Yale contributed their CAS implementation Work with partner projects to ensure meeting requirements: •uPortal ( •Open Knowledge Initiative ( •Shibboleth Define architecture and interface to which many webiso implementations can conform

WebISO architecture + interface Application interface •many issues similar to Shibboleth target arch •webisos typically supply plain old userid to targets –what about authorization data? –what about privacy protection? •forced/step-up authentication –app specifying authn method (pubcookie supports both Kerberos and SecurID) –app selectively turning off SSO •session management –e.g., "single sign-off" from all apps at once

Webiso design centers Webiso implementations differ in approach •support for admin apps: high security/control •support for student-run apps: simplicity, ease of install/support •assume local software on client (eg Kerb plugin) •cross-DNS-domain support required •assume underlying authn infra (Kerb, X.509) •support home-grown apps, package apps, static pages, portals, backend services, etc Can one package do it all?

Application interface 2 The 3-tier problem (aka delegation) •seen by many app servers that need to access backend services (eg IMAP) on behalf of user •seen by all portals that act as intermediaries •many sites implement "practical" solutions •can webiso provide a standard approach? •will any solution be dependent on underlying delegation technology, eg Kerberos or X.509? •is this a WebISO project problem?

Conclusion WebISO project up and running Pubcookie code available Architecture/interface issues engaged Sites still reinventing, so need is there Partner projects need support