Shibboleth Developers

[Derek Atkins <>]

                Shibboleth Proposal (abreviated version)
                           Derek Atkins
                          June 26,  2002


This document is a short, abbreviated, technical overview of my
proposal for the Shibboleth "service provider" implementation of the
SHIRE, SHAR, and Resource Manager (RM).  More detailed information is
available in the full proposal, or details can be explained on
request.

At a high level, the proposal is to create a set of shared libraries
that implement the core functionality, create a standalone process
that implements the SHAR and a data cache, implement the SHIRE and RM
as Apache Modules, and use IPC (implemented as ONC-RPC) for the SHIRE
and RM to communicate with the SHAR/data cache.

The high level picture looks like this (best viewed with a fixed-width
font):

+----------------+  +---------+   +------------+
|  Apache/WWW    |  |  Core   |---|    SHAR    |
+-------+--------+  | Library |   +------------+
| SHIRE |   RM   |--|         |   | Data Cache |
+-------+--------+  +---------+   +------------+
   |        |                        |     |
   |        +------------------------+     |
   +---------------------------------------+
                      RPC

The core library would implement the major functionality and also
provide a common Configuration (including Policy) interface for all
three pieces.  The SHIRE and RM are simple stub apache modules that
call into the Core Library, and use RPC to communicate to the Data
Cache.  The SHAR, while logically its own component, shares the
"process" with the Data Cache server (why complicate matters with
multiple applications?).

The goal of this design is multi-fold:

  1) Separate the Shib functionality from the Web Server
     implementation.  My understanding is that Shib wants to support
     ISS (and potentially other web servers) in the future, so
     implementing the core Shib functionality is a reusably library
     allows easier porting to different web server architectures.

  2) Centralize the data caching of sessions, handles, and attributes.
     Each piece of the Shib architecture has its own requirements for
     what data needs to be cached, but all of them overlap.
     Centralizing the storage minimizes the issues of "shared memory"
     or "threading" or other cross-platform problems that would arrise
     from other designs.  This design also allows the implementation
     to replace the storage mechanism without changing the
     applications and plugins.  ONC-RPC is a small, simple, portable
     protocol to model an IPC and exists on every platform in
     existence.

  3) Centralize "application" and "policy" configuration.  This
     eliminates the possibility of misconfiguration between the
     various Shib services.  Imagine the havoc if the SHIRE, SHAR, and
     RM each had a different idea of what applications exist, their
     URLS, and their policies.  The SHIRE might not aquire a new
     Handle, the SHAR might aquire the wrong attributes, or worse.
     For flexibily and extensibility, I propose to implement the
     policy configuration as a scheme plugin.  This allows a simple
     text-based configuration but also extremely powerful paradigm.


Feedback, questions, or suggestions are always welcome.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       

                        PGP key available

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--