1、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:
2、 do something about it brief search for likely sharable implementations U of Washingtons “pubcookie“ chosen as starting point project started to make “appropriate progress“ now looking at architectural issues,WebISO project status,Its live: web: http:/middleware.internet2.edu/webiso/ email: mace-web
3、isointernet2.edu, 40 on list phone calls: bi-weekly, 3:30PM ET Tuesdays active work on refining project goals Pubcookie distribution 10 sites with code, 1 non-UW deployment (CMU), a few pending; BSD-style license CMU-contributed changes being incorporated freely-available distribution posted shortly
4、,WebISO defined,Organizational web-based sign-on system Typically includes: single sign-on (only “type something“ once to access multiple targets) use of standard authentication backend (LDAP, Kerberos, NIS, NT, etc) keep passwords away from application web servers (have them only entered into “webl
5、ogin“ server) “Most reinvented technology of the 90s“,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, promp
6、t 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 produ
7、ction 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
8、 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 Work with pa
9、rtner projects to ensure meeting requirements: uPortal (http:/mis105.mis.udel.edu/ja-sig/uportal/) Open Knowledge Initiative (http:/mit.edu/oki) Shibboleth Define architecture and interface to which multiple webiso implementations can conform,WebISO architecture + interface,Application interface man
10、y issues similar to Shibboleth target arch webisos typically supply plain old userid 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 manageme
11、nt 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 r
12、equired assume underlying authn infra (Kerb, X.509) support home-grown apps, package apps, static pages 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
13、 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 http:/middleware.internet2.edu/webiso/,
