Shibboleth Developers

["Howard Gilbert" <>]

> > 2) What does the Web Service look like 
> 
> Well, Walter and I were, I think, hoping that the J2EE session model would
> save us here, and avoid the need for both a physical session handle
> separate
> from that, and from any web service stuff. It occurs to me that maybe
> sessions in Tomcat are confined to a single context. I can see how that
> creates a problem for the "single SHIRE URL" model I want, but seems like
> there should be a way around that. Something simpler than a web service
> anyway. That creates a lot of nasty questions about securing that query.

The Session object (found through the Request object) could certainly cache
attributes and contain a reference to an object with a getAttribute()
object. From the user's point of view, there is no need for a handle to be
visible. However, if the SHIRE/SHAR is in another JVM, then under the covers
the classes implementing this application interface have to communicate,
just as the current code uses ONC RPC. To communicate from Java, however,
you need to use RMI, Corba (but only with the addition of a J2EE EJB
container), or Web Services. If you use Web Services, you support other
languages and runtime environments.

If there was one feature that ONC RPC did not have, it is Security. The SAML
traffic currently being used is a Web Service (it uses HTTP and sends data
in SOAP XML). 

> 
> If we absolutely *had* to remote the query right off the bat, the obvious
> choice would be to simply use SAML protocol again, with the local web
> service acting as a proxy AA forwarding the same assertion it got from the
> real AA.

I have to admit I missed this one entirely. Of course! Make the SHAR operate
as a proxy AA. Simply reuse the AQM and ARM. You also get to reuse the code.

I see three code units:

1) Code to take the POST 
2) Code to query (AQM/ARM) and cache attributes
3) The Session object interface to the application

In the simple single JVM case, all three code units run together. If the
SHIRE has to be on a different JVM, then 1) and 2) are used on the SHIRE
while 2) and 3) are used on the application JVM. The AQM is directed to the
AA on the Shire and to the Shire on the application. The cache logic is the
same in both places 


> > Filters get initialization parameters from the context
> > configuration. Global stuff gets initialization parameters
> > from the global server configuration. This is just a case of
> > deciding what to carry over.
> 
> Yes, but as we found with Apache, it's turned out to be a bad idea to rely
> on target-environment-specific configuration when possible. We used to put
> a
> lot of stuff in httpd.conf, but it's much better to consolidate things
> outside the web server's config, and I think the same goes for Tomcat,
> personally. It's always a trade-off, but I think we got this part right.

OK, then what gets put in the web.xml file parameters is the URL of the
external configuration file (which can be a local file URL or an http: URL).
What doesn't work is to expect the configuration file to be in the current
directory, because in the typical Application Server there is no good way to
predict what the "current directory" will be when the server starts up, and
generally you won't have write/add privileges to that directory even if you
could figure it out.

It is still marginally simpler to parse an XML file with the support we
already have in the code than to parse some different file format.