Shibboleth Developers

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

Last monday, we spent some time discussing use cases and requirements 
for a grid-related scenario, the Darwin Streaming Server, and WebDAV. 
Investigation is continuing for all of these. We'll return to these 
topics during a future call. As always, please send questions and 
new info  on this topic to the list.

Agenda:

1) Current programming issues/questions

2) Discuss a proposal - A Rationalized Approach to Shibboleth 
Application Domains

        http://www.columbia.edu/~wassa/application.domains/app.domains.html

3) Conversations about a native java shib target implementation 
continue, but this doesn't look to be a very complex situation. 
Today's discussion is focused on the more complex question of shib 
integration with a portal (and where the situations being described 
often look like 3-tier problems). There's a basic question that must 
be addressed -- should channels (backend applications, in general) 
trust the portal to obtain, cache, and then forward credentials and 
attribute assertions? This is what many implementations do today. Is 
this still acceptable? We're looking for use cases where the 
application should NOT trust the portal. Here's a couple of 
proposals, in DRAFT form:

(from Walter)

The Example State University IT department maintains a central 
metadirectory service, which feeds identity and other information 
into various data repositories (including an OpenLDAP directory, 
several DBMSs, an NIS+ system, and Active Directory) across the 
campus.  While some of the data repositories are managed by the 
central IT department, some are managed by other administrative 
departments, such as Human Resources.  Others still are under the 
purview of the various colleges.  The administrative and 
data-management functionality of the metadirectory is exposed via Web 
Services.

The metadirectory allows some user attribute information to be marked 
as "private".  Information that is marked as private continues to 
flow into various central IT and administrative systems, but is not 
included in the feeds to the public ldap directory or to the colleges.

Several front-end systems, including the university's student portal, 
the HR website, and the registrar's office web console allow the user 
himself or some designate to modify this privacy setting.  It is 
important that whenever a user's privacy settings are modified, 
especially when information is made public, there is a degree of 
certainty that the user or a designate of the registrar was 
personally involved in the transaction.

(from JSTOR)

"meta-searching":

   1. User contacts a "meta-search engine," presumably running on a
      server at his/her institution (although maybe not, maybe it's
      running on some consolidator's server -- auth gets more
      interesting in that case.)
   2. This engine submits searches to a number of online resources, of
      which JSTOR is one, using some mechanism (currently, to search
      JSTOR, the engine has to "scrape" the HTML, but we're in
      discussion about implementing an XML-based interface).
   3. The search results are then consolidated and presented back to the
      user.



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

   http://archives.internet2.edu/

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