WEB Initial Sign-On Overview Draft
draft-internet2-webiso-overview-01.txt
Ryan Muldoon, Scott Fullerton
Date: 11/12/2001

Abstract

This document discusses in general terms how WEB-ISO operates, the
Pubcookie model, and the portal as a special case.

1. Introduction

Web Initial Sign-On allows a user to log on to many applications
seamlessly, without having to authenticate his or her self multiple times.  
Consider the following example.  Jane wants to visit the UW bowling site
to update averages and get the averages of the other teams' members.  She
then wants to get to the event calendar to see how the current tournament
schedule fits in with other activities going on.  Using WEB-ISO, she will
be authenticated once when she goes to the bowling site.  When she
requests access to the event calendar an exchange of information will take
place 'behind the scenes' to establish her credentials.  Once established,
she will be allowed into the site, and from her perspective her entry into
the site will be seamless.

2. Problem Statement

In order to be granted access to restricted services and information, web
users need to prove their identities.  For the most part, the user does
this by providing authentication credentials (e.g. userid and password,
certificate, etc.) to each and every application.  This is an obvious
inconvenience to the user.  Additionally, it poses a hindrance to efforts
to integrate services under a single umbrella.  Further, it requires
redundant development effort for each application that authenticates users
independently.  Finally, in the absence of a good Web-ISO infrastructure,
portals are often asked to perform this responsibility by caching user
credentials, a relatively insecure arrangement. Web-ISO benefits

>From the point of view of the end-user, Web Initial Sign-On (WEB-ISO)
creates a more seamless experience for people who use several restricted
web-based applications or services in a single domain.  In that way, it is
analogous to RACF or TopSecret logon facilities, which provide single
sign-on capability for the mainframe.  One logs in once and thereby has
access to a whole series of resources in that realm.
 
>From the point of view of the application developer, the authentication
process can be streamlined using a common, proven set of libraries and a
common set of directory services, the development and maintenance of which
is not the burden of the developer.

>From the point of view of the service provider, the security of the
common authentication process using common libraries has been proven.  

3. High-level view 

WEB-ISO as it is treated in this document requires a compliant login
service, and WEB-ISO-aware applications.  It works as follows. 

When the user requests access to a secured application, the application
checks for WEB-ISO formatted user credential.  Upon finding it, it accepts
the user, i.e., it considers the user authenticated. If the credential is
not present, it redirects the user to the login service.  There, the user
logins in, receives the necessary credential and is redirected back to the
application which grants access.

4. The Pubcookie model 

The University of Washington ISO technology, Pubcookie, has been presented
to the higher education community as a starting place for a shared ISO
effort.  This document borrows from the data and the semantics of
Pubcookie, which in turn has drawn heavily from Kerberos.  Pubcookie
tokens fall into three types: 

    The Login token (cookie), which is issued by the login server upon
    initial login.  It has a timeout, on the order of eight hours. 

    The Granting token, also from the login server, is issued every time a
    user wants to access a new secured site.  It has a timeout on the
    order of fifteen seconds.
  
    The Session token, issued by the secured site, has an inactivity
    timeout on the order of thirty minutes. 

When the user tries to access a secured application, the application will
check for the presence of a granting token.  If found, it will issue a
session token.  The session token exists for the duration of the user's
session with that application. 

If not found the user is redirected to the login server where she
authenticates.  Then the user is issued a login token and a granting token
and is redirected back to the application which uses the granting token as
a basis for trust that the user has been authenticated.

5. WEB-ISO and the portal 

A portal presents special issues with WEB-ISO (portal is here understood
as a type of web application that draws information or services from
various sources for presentation to the user).  Where the portal mediates,
it is generally a high virtue not to make the user login to each of the
back-end services.  And because the portal mediates, it must negotiate the
authentication with those back-end services for the borrower, in the
strictest sense, on behalf of the borrower.  This poses a constraint on
how WEB-ISO can operate.

Explicitly, there are two authentication relationships, user-portal and
portal-app.  In the user-portal relationship, the portal can be considered
an app and participate in WEB-ISO exactly as discussed above.  In the
portal-app relationship, the portal is in some senses standing in as for
user forcing modifications to that WEB-ISO pattern.

Often the work-around for this has been to have the portal cache
username/password or other secret information and present this to the
mediated app as if portal were user.  In cases where the mediated app will
only accept this kind of authentication, it may be required.  As mentioned
above, though, this method of handling WEB-ISO should be avoided where
possible.

A better approach would be for the portal to set up a trusted relationship
with the application ("Hi, App.  I'm portal."  "Hi, Portal").  Following
this, the portal would present the user-id for the end-user, and because
of the trusted relationship, the app would accept this ("App, this is
George's id.  Please present yourself as if for George").  This
arrangement has the advantage of protecting the user's password, etc.  It
also has the advantages of letting the application optimize the connection
to the portal and choose a portal-friendly presentation.

Another alternative worth exploring might be for portal to have the
trusted relationship with the login server, instead.  The conversation
between portal, app and login server would go like this:

[Portal] (no trusted relationship with app) "App, here I am"

[App]    "I'm sending you (whoever you are) to login server to get a a
         granting token."

[Portal] (to login server)  "Hi Login Server"

[LS]     "Hi portal"

[Portal] give me a granting token as if for George

[LS]     "Here you go"

[Portal to App]  "I'm back with Granting token"

[App]    "I will let you in, George.  Here's a Session token"

This arrangement has the advantage of letting an app use the standard
WEB-ISO scheme whether communicating with portal or directly with the
user.  

6. WEB-ISO and access to services on remote sites

So far, we have discussed authentication to local sites only, sites in the
same domain as the user.  What if the secured site is at a different
institution, say a library at Michigan.  In this case, inter-realm
authentication and authorization services are needed as are expected from
Shibboleth (see related efforts below).  Here too, though, WEB-ISO can
play a role in supporting the local authentication process in the exchange
that takes place between the institutions.

7. Related Efforts

Shibboleth: Web Initial Sign-On is intended to operate within the domain
of a shared authentication service.  Shibboleth, a joint project of
Internet2/MACE and IBM, is developing an architecture, framework, and
practical technologies to support inter-institutional sharing of
resources.  Specifically it will handle the secure exchange of
interoperable authorization information which can be used in access
control decisions (cf http://middleware.internet2.edu/shibboleth/).
Shibboleth is intended to work with (although not require) local Web-ISO
infrastructure.  Making sure that our Web-ISO solution integrates well
with Shibboleth is an important objective. Shibboleth is currently in the
detailed design stage and is scheduled for pilot implementation in 2001 or
early 2002.

JA-SIG uPortal:  This is a collaborative effort of a large number of
higher ed institutions to develop an open-source java-based portal
frameworks.  It has acknowledged the need to interoperate with a WEB-ISO
strategy and is encouraging the efforts of Internet2 Web-ISO.  It has also
declared its alignment with Shibboleth.

Open Knowledge Initiative (OKI):  Analogous to uPortal, this is a
collaborative effort led by MIT and Stanford with active participation
from some five or so institutions (including UW) to develop an open-source
learning management system.  It will need to accommodate a WEB-ISO
strategy and is supportive of the Internet2 efforts for WEB-ISO and
Shibboleth