Shibboleth Developers

["Scott Cantor" <>]

In lieu of a meeting, just a summary of some issues I've seen come up or run
into myself. Things seem pretty ok overall, modulo the lack of decent docs
from me.

Origin

- Duke reported back with a log indicating the metadata reloading code is
leaking file descriptors, so hopefully a fix can be created for this.

- Seems like we want to incorporate the WAR configuration approach we've
been steering people toward into the docs as soon as we can.

- Howard ran into an issue with the SOAP schema that we eventually need to
track down and make sure won't crop up going forward. I'll file a bug on
that as a placeholder until we know more.

- I was a little confused in my testing by the fact that the Handle Service
"verifies" the relying party before accepting/allowing the use of a
particular NameIdentifier/Principal mapping approach, but the Attribute
Authority doesn't. Seems like it could do this pretty easily and would be a
basic ACL against use of global identifiers except by particular requesters.
I'll file an enhancement on this.


Target

- A few build issues, nothing too dramatic, although there seem to be
problems on x86_64 related to libtool that may not have easy solutions.

- Definitely need to manage minor point releases so that "make dist" will
produce different filenames, so I suspect we'll need to decide on a cvs
strategy for this, if any. Thoughts from those more experienced welcome.

- Windows issues: A major bug cropped up on IIS due to lack of testing, this
has been fixed, but I'm also looking into a problem on Windows 2000 that
causes the filter to hang on a lock somewhere in the XML parser. Strangely,
the problem can be traced to the log4cpp configuration used, but I haven't
found a pattern that makes sense yet. Even the SHAR sometimes crashes when
the log is configured in some ways due to memory corruption. I think the
root of the problem is that the logging gets configured twice, once by
default, and once using the properties file after startup.

I did find some race conditions in the code that I don't think are ever hit,
but will patch anyway. Am becoming convinced log4cpp will drive me insane,
but my early look at the Apache log4cxx library wasn't promising. It's quite
immature still and may be worse.

- Apache POST handling: definitely still issues that cause POST failures
under certain rare network conditions. Very hard to pin down. I've checked a
few other projects, and did see a possible tweak to apply to the 1.3 code,
which I did. My impression is that pubcookie, for one, uses about the same
code for POST that we do, so it would be interesting to see if any issues
have arisen there. Worst case, we could build a CGI version of this piece
(actually would be very easy right now).


1.3/future development

Once some of the 1.2 problems are dealt with, and some docs are written, a
SAML 2.0 metadata plugin is probably the next work item. The plan is to
create a plugin for 1.2 that supports the standard scheme and some set of
its features, and then release a "1.2.1" that supports both formats. Then
the API can be tweaked on the 1.3 branch to better align to the standard and
a plugin for 1.3 that supports both formats can be built. This should be a
step toward prototyping an artifact profile implementation for the E-Auth
project.

Logging (see complaints above) is probably another near term work item given
all the problems with it.

-- Scott