Shibboleth Developers

Phone #:  (800) 541-1710
Pin #:  0142203

(My family and I will be away this weekend, and won't be returning 
until sometime on monday. If we're not back in time for this call... 
I've asked RL Bob to act as convenor/moderator.)

Agenda:

1) Current programming issues/questions

2) Sort and begin to prioritize the use case landscape.

Two of the "shib design discussion" topics (Use of Shib/SAML in 
non-browser, non-web applications, Use of Shib/SAML in n-tier 
situations (including portals) ) have each managed to attract a flock 
of use cases and potential applications. I'm interested in defining 
the next steps -- which may mean triaging this collection, to allow 
us to continue to make progress, and avoid getting  trapped in 
ratholes from which there is no escape.  I suspect we may need to 
define which of these are worth worrying about (and which not), which 
need general solutions (and which not)

There is some overlap between these two topics (ie altho the n-tier 
question often surfaces as "the portal problem/question, there seem 
to be a growing number of app's that also (potentially) include 
n-tier problems). And, in many of the portal scenarios, the channel 
may be communicating with the backend over something other than HTTP.

Here's a list of the applications that I've collected so far, with 
some crude effort at categorization:

	pseudo-web (WebDAV, Streaming Server) (pseudo because they 
ride over http, or something very similar to http)

        grid (grid ftp, OGSI, begin to use attributes)

        Digital  repositories (fedora (native java), dspace, NSDL, etc)

        3-tier app's (E2E - MattZ, E2E - MD (Chas), "things like meteor" ) )

        enterprise-enable (jabber)

        non-browser app's (lionshare -- add shib to the gnutella protocol?)


As  I stare at this list, my inclination is to try  to identify the 
defining attributes of each of these (which I guess means finding 
good use cases  (-:  ), identify the constraints, try to find the 
overlaps, and then prioritize.....

--------

1) WebDAV -  desktop OS mount remote WebDAV accessible file system; 
applications (eg Dreameaver) then r/w to local disk. Standard WebDAV 
clients only support some specified HTTP authn methods; could use 
apache/mod_dav in backend (already shib-enabled).

Constraints: might be able to provide an alternate client for the desktop?

2) Darwin Streaming Server - clients (eg Quicktime Player, 
RealPlayer, Windows Media Player) speak rtsp with the server .... 
RTSP is an  IETF protocol, and RTSP turns out to be a first cousin to 
http. In particular, the RFC describing RTSP contains this bit of 
text:

D.1.2 Authentication-enabled

   In order to access media presentations from RTSP servers that require
   authentication, the client MUST additionally be able to do the
   following:
     * recognize the 401 status code;
     * parse and include the WWW-Authenticate header;
     * implement Basic Authentication and Digest Authentication.

So, the RTSP authn mechanism is modeled on (copied from?) http... and 
if I protect a movie within SS, my player pops up a dialog that looks 
a  lot like a browser's Basic Authn dialog.

The server allows me to put qtaccess files into directories 
containing media files, and they have the same syntax as htaccess 
files. The server seems to have a plugin structure; its possible shib 
could provide an authz plugin....

Constraints: can't change clients, may be able to provide plugins in 
the server.

3) Grid  - ESG-Grid use case -- grant access based on attributes of 
the requestor, potentially very large community of requestors, would 
like to avoid requiring that individuals be assigned PKI credentials 
and managing individual ACLs at the target; von - wants to find a way 
to use this mechanism across several application protocols; 
currently, grid apps use traditional authn model (authn to target) 
rather than authn locally and provide signed  assertions....

4) Digital  repositories -- ? (dspace, fedora, NSDL, etc)

5) E2E - MattZ --

He's also described scenarios where there's a web front end that 
requires authn, and then allows people to run tests (where which 
tests, and  which endpoints, are a function of who they are and their 
role; eg someone in the NOC at brown could run tests against brown 
but NOT uwash; or look at brown  performance data but  NOT uwash 
(this last one is probably 3-tier.....)

6) E2E - Middleware Diagnostics (Chas) - he imagines lots of 
distributed log data, some of it aggregated centrally, access 
strictly controlled (by name, by role, by site), lots of concern for 
privacy issues vis-a-vis access to logs that  describe a person's 
behavior.

7) "things like meteor" - browser user,  typically access via a web 
page/portal, redirected to an authn provider, who returns a signed 
SAML authn assertion (somewhere along the line, meteor picks up the 
person's SSN), sends a query (containing the subject element) to 
several backends (over SOAP), gets responses and displays them.

8) jabber --  -- may just need  trust fabric between servers -- 
allowing jane@brown to join an access controlled chat room @ uwash; 
with "enterprise enabled jabber", clients are doing authn to local 
server (using kerberos); not clear whether authn assertion originates 
from  jabber client or server ....

9) lionshare - (use case based on limewire) - desktop client obtains 
handle (after authn to local handle dispensing service?), sends 
retrieval request to remote  server (including the handle), server 
obtains attributes, server makes authz decision, server returns data.