вход по аккаунту

код для вставкиСкачать
Internet2 WebISO Project
RL "Bob" Morgan, University of Washington
October 3, 2001
How it came to be
Project status
WebISO defined
Project goals
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
• project started to make "appropriate progress"
• now looking at architectural issues
WebISO project status
It's live:
• web:
• email: [email protected], 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
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 "weblogin" 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, 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
Work with partner projects to ensure meeting
• uPortal (
• Open Knowledge Initiative (
• Shibboleth
Define architecture and interface to which
multiple webiso implementations can
WebISO architecture + interface
Application interface
• many 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 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
• 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
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?
WebISO project up and running
Pubcookie code available
Architecture/interface issues engaged
Sites still reinventing, so need is there
Partner projects need support
Пожаловаться на содержимое документа