Shibboleth Developers

[Chad La Joie <>]

Let me start off with a couple of assumptions that I'm working under.

- 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.

- The SP should share, as much as possible, the existing C++ SP  
configuration files and functionality.

- Java is a different environment than C++ and certain constructs  
used in the C++ code will not make sense, in those cases, the Java  
idioms should be used.

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.

It is our hope that time will permit us to explore some additional  
mechanisms such as a Tomcat Realm or JAAS implementation of the SP as  
well, but we are not making any promises that either is even  
possible, let alone capable of being done in a timely manner with  
existing resources.

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.
 - Attribute handler: the discussion on this started yesterday
 - Authorization engine: at minimum an interface will be provided so  
that authorization checks can be expressed and evaluated in-flow
 - Caching: to cache information and used in replay attack detection
 - Artifact resolution: for resolving artifacts, of course

The service provider is expected to support all of the SAML 1.0/1.1  
profiles that the current C++ SP does as well as the SAML 2.0 ones  
that will be supported by Shibboleth 2.0.  To date I believe we've  
settled on that being the SAML 2.0 single sign on, single logout, and  
attribute request profiles.

If anyone has comments/questions/suggestions please let me know.  i  
will not be answering questions about APIs or implementation  
details.  They are not worked out yet.