Shibboleth Developers

[Scott Cantor <>]

I checked in a tested snapshot of the target libraries that implements the
new "application-oriented" design, with URLs mapped to application IDs which
the origin will eventually use to set policy. The session and attribute
cache is also redesigned to be per-application instead of per-vhost, so it's
possible to segment the URL tree on a vhost with independent Shibboleth
behavior.

I also changed a lot of the lower-level APIs so that eventually all the
different target configuration (including federations, trust, AAP, etc) can
be overridden by each application during each transaction, though I haven't
fully implemented that support yet.

Lastly, I fixed a design problem that required the earlier version to
reapply the attribute filtering rules on every web request, even after all
the invalid values had been stripped, which should support larger attribute
sets with less overhead, though I doubt it matters for now.

I have the Apache 1 and ISAPI modules recoded to build and run, but I
haven't fixed the Apache 2 module yet. It's not significant work, I just
don't have the headers to use on my development box.

The next stage of work is to design the new configuration system and plug it
in to this new design so that all the config data is obtained on a
per-application basis, and then we should have a stable release to start
documenting.

The plan is to implement an XML file that can include the other XML
formatted config data inline or in separate files, and make the whole thing
reloadable the same way they are, except for some of the stuff that can't
change on the fly easily like the shar socket, and some of the Apache
configuration details. I think it will be easy for people running simple
target deploys to set up, but will potentially support really complicated
situations well. It should all be directly portable to the Java target and
other ports in the future.

-- Scott