PHP single sign-on system

I started working offline for the main site about 10 months ago. Bogdan and I thought of a way to improve user experience throughout the site, so I came up with the requirements for a PHP single sign-on system. While searching with Google, the most complete set of features seemed to be described at this page: http://www.sandiego.edu/webdev/coding/sso.php.

ACL
Right, so we had user authentication, group assignments, ACL (access control lists) based on users and groups: we could deny a specific user, allow only a group, manage sections differently based on combinations of permissions and whatnot.

Not-so-redundant user database
However, since most registered users were on the forum, we had to find a way to use the Invision Power Board user database.
We wanted this system to be available and quickly deployable on most sites we design, where IPB might not be available - so the database authentication was made to fail safely and nicely to a static mode of authentication.

Mmm, cookies
Users will want some nice features, so along came automatic site sign-on with the aid of cookies. This has been a bitch to implement since we already had sessions and cookies behave differently.
That is: cookies update after the page has loaded, sessions before, which makes sense once you know the inner workings. This means that we had to put some redirects to a blank page which then redirects to the intended page, so that the intended page ends up with the latest cookies.

Into the time machine
Some features of the site (like posting comments) are made available only to registered users. We have a link that sends the user to the registration page. But after all the steps are completed, the user usually forgets why he/she wanted in the first place. As a side effect of the previous feature, we are able to send them back to where they were when the registration form kidnapped them.

What's the deal, anyway?
The immediate application of this sign-on system was that with a single account a user could access (almost) all features of the site, unlike the 3-4 accounts that were previously needed (fear not, they were never implemented).

Where's my menu?
Another nice feature was that we could show different menu options based on the group in which the users take part (or not).
For example:
- normal users can post comments, buy stuff from the shop
- moderators can edit/delete articles, comments, download descriptions
- vendors can upload their stuff to be entered into the shop, view statistics about their products
- guests can pretty much do anything, except the above things. Oh, wait, they can log in.

Also, some sections of the pages are available only for some of the users/groups. For example, an administrator can edit more fields than a moderator.

What's our gain?
Well, administrators can impersonate just about any user. This is useful when we have to take matters into our own hands and edit products for a vendor. Yep, free stuff (our site) hardly catches on to some people.
And then there's this new feature: some actions not performed by an administrator can be put into a queue to be approved later on. Currently, comments are queued and then they have to be approved before rants and tribulations are available to the public. The same thing goes with vendor registration - it has to manually inspected before their modification makes it into the database (and, conversely, into the site).