Shibboleth Developers

[Scott Cantor <>]

After an exhausting day...

Things went fairly well, with a few problems. It works, but it's not
entirely usable. I guess that's the definition of alpha.

Some things to fix in the module:

It faults if the shiresession directory is inaccessible for some reason
(like bad permissions). That should be easy to turn into a server error
message, assuming it's returning an error from a file API.

We need to expend some brain energy on exactly how and when to encode
certain URLs that get passed around. As it is, I had to fix the module
to use r->unparsed_uri instead of r->uri when composing some of them,
particularly the one that gets hidden in the WAYF form. The Brown proxy
uses weird URLs that get mangled internally by Apache.

Some of the URLs certainly need to be URL encoded (I inserted some code
to start with this), but it's somewhat confusing trying to work out
which ones and when. It only breaks things when you use odd characters
in URLs or URLs with query strings, so it works for simple ones. It's
good enough now for the alpha.

Biggest issues:

It's segfaulting when children get cleaned up by Apache. There's either
a bug in the cache cleanup code, or in the Xerces cleanup code. I can
experiment a little to figure out which cleanup activities fault or not.
This isn't crucial, since cleanup dumps all the memory anyway, but it's
ugly in the logs.

It's slow. I mean really slow. The Brown home page through the proxy
takes minutes to load, with 50+ requests causing dozens of cache misses
and attribute requests. I tried throttling the children down, but that
causes the proxy to seemingly hang. I don't know why. It doesn't seem to
be related to our code. Maybe the proxy itself is unreliable under those
conditions.

It's notable that everything is slow with the thing, even once the
caches are populated, so I don't know how bad this would be with a
normal server. It doesn't seem reasonable to me that a filtering proxy
written entirely in Perl would work without big hardware, which is
pretty much what Richard said. The box has 256M of RAM, so maybe it just
isn't a good test case.

It's clear that we will need to externalize the SHAR cache to deal with
the lack of threads to get adequate performance. We can talk about
whether to externalize the whole SHAR, or just the cache itself. I lean
toward the former, partly because that will give us a model close to the
architectural model in which multiple sites could share a SHAR.

Deployment was fairly routine, except that I had to learn a bit of
Tomcat, and package up a shibdest.war deployment file that is a little
simpler than the one we're using for development. This one has just the
SHIRE and the SnoopServlet for testing. One major problem was the fact
that /usr/local was read-only, so I needed to package up all the
libraries in use (libcurl, OpenSSL, Xerces, mine) and stick them all in
/opt/local/shib. This seems to work ok. People can override the copies
we provide by putting it late in the loader path.

Getting it work with the proxy was simple. I added an .htaccess file to
that proxy folder and that protects all the proxy sites. I don't know
how to protect individual sites, it didn't have subfolders for each
proxied site, which I thought it would have.

The port back to Sun went ok, had to tweak a couple lines of code to get
it to compile, and I made the changes on shib1 also to keep it all in
sync. I have a compressed tarball for distribution for Sun now.

I documented all my steps as I went along, so after a little more
testing, I'll send it along for inclusion in the deployment guide.

Things to do:
Get affiliation implemented.
Build a Linux distibution.
Insert a LICENSE file in the tarballs.
Sleep.

-- Scott

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

    http://archives.internet2.edu/

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