Shibboleth Developers

["Scott Cantor" <>]

> - People are more likely to attempt to use the Java SP code for non- 
> web applications (web services, grids, client/server, etc.)  
> applications than the C++ code.  Thus, as much functionality as makes  
> sense should be moved into a set of core code that is divorced from  
> things like the J2EE servlet code.

As I've said before, the C++ code is completely designed this way. The only
bits that know anything about browser profiles or web servers are the parts
that have to.

Trust code, metadata, session caching, querying, attribute filtering, etc
are all in self-contained modules.

> Initially the Java SP will be a Servlet 2.3+ Filter.  All incoming  
> requests will pass through this filter which will use a request map  
> mechanism to determine if the request is for a protected resource.   
> If so, start the shib flow.  This request map portion will be tied to  
> the web portion of the code, though a portion of it may be reasonable  
> to extract out and pushed down into the core set of library.

Mine is a separate module. It even sort of/kind of has support for non-http
request URLs, not that it's used anywhere.

The way I would do things, as in C++, is to tie the RequestMap support into
the container in such a way that you can specify settings in both a native
webapp form (web.xml?) and in our config file.

> Currently the following core subsystems are planned, some of these  
> may be reflected in, or available to, Servlet specific APIs:
>   - Session manager: this will manage sessions for the service  
> provider and deal with things like timeouts, login/logout tracking,  
> etc.  I've heard a lot about usage metric gathering here at the JISC  
> conference, this is where you'd do it.

Yes, and I'd like to piggyback on this to some degree, since my cache needs
work.

-- Scott