Tech:Acegi Upgrade

[Edit]Description

Acegi is currently on milestone two in the buildup to their next major release. The new release will offer a significant number of improvements, including better LDAP support, easier configuration, and tighter Spring integration. This upgrade is also a chance for much of the legacy LDAP and authentication code in JAMWiki to be fully converted to use Acegi, thus offering more flexibility to users.

UPDATE: Acegi (now Spring Security) version 2.0 has been released. Upgrading to the new version will be the major focus of the 0.7.0 release.

[Edit]Author(s)

[Edit]Status

Until Acegi is closer to a final release it probably doesn't even make much sense to start this work. That said, cleanups to modify existing JAMWiki code to make better/cleaner use of the current Acegi infrastructure would be welcome.

The actual conversion to the new Acegi functionality will be a significant opportunity to improve JAMWiki and will almost certainly warrant a major bump in the JAMWiki version number (example: 0.7.x → 0.8.0).

[Edit]Comments

I didn't take a closer look to the changes in Acegi 2.0 up to now, but I think, for a better integration into JAMWiki, a big change would be necessary: jam_recent_change and jam_watchlist should take an username instead of of the wiki_user_id, without foreign-key constraints to jam_wiki_user. Also, the interface QueryHandler should take usernames instead userids for changes on watchlist. --hp 14-Apr-2008 00:14 PDT

I think you're right that it will be necessary to switch from using user ID to login in many places. Writing and testing the upgrade scripts for that is gonna be ugly, but in the end it should be a worthwhile change. -- Ryan 14-Apr-2008 08:13 PDT

[Edit]Update June 2008

JAMWiki 0.6.6 is out, and I'm planning on beginning work on the Acegi upgrade next, with the goal of making that one of the key features for 0.7.0. I'll be on vacation through mid-July, but once I return I'd like to start work. As part of this integration I think it makes sense to begin using user logins (instead of ID) as primary keys to make LDAP integration easier (as suggested above by Hans), and as a result there will be some pain as the database schema will have to change. It should be possible to automate everything so that the upgrade remains painless for users, but if not then this approach may need to be re-visited. -- Ryan 04-Jun-2008 22:15 PDT

[Edit]Update August 2008

The transition to Spring Security 2.0 is underway, but "remember me" functionality is broken in the current JAMWiki Subversion code (as of revision 2271. I suspect that this issue may be due to http://jira.springframework.org/browse/SEC-924 which will be fixed in the next minor release of Spring Security. Rather than spending any more time trying to track down this problem I'm going to focus on simplifying JAMWiki's Spring Security configuration so that integrating with LDAP, OpenID, etc can be done using Spring Security's new and very simple namespace configuration. -- Ryan 24-Aug-2008 19:45 PDT

revision 2277 fixes the "remember me" issue. For the record, the error was a reference to the old Acegi token name in login.jsp and not in the Spring Security code. -- Ryan 30-Aug-2008 22:59 PDT

[Edit]Update September 2008

There is more testing needed on the new Spring Security configuration, but overall it seems to be much simpler than the old version. There are additional simplifications possible in regards to specifying virtual wikis in URLs, but per the project's author they will be more easily implemented when Spring Security 2.1 (the next major release) comes out.

The next step in the JAMWiki integration will be to more easily support login/authentication from LDAP, OpenID, and other systems - currently there are a number of foreign key constraints in the JAMWiki database that require a jam_wiki_user entry, but that value is created only during JAMWiki registration. I suspect that some painful database changes may be required, but it might also be possible to just automatically create database user records as needed when an authenticated user is available in the session but not in the database. -- Ryan 06-Sep-2008 08:33 PDT

[Edit]Update October 2008

I've started on round two of the Spring Security upgrade, which is meant to get the JAMWiki code more in-line with Spring Security's defaults. Initially there is going to be a lot of core code affected, so those with weak stomachs are advised to avoid the latest Subversion code for a while. The eventual goal is to make it possible to configure Spring Security LDAP or OpenID integration out-of-the-box, but to do so means fundamentally re-working the JAMWiki jam_wiki_user and jam_wiki_user_info tables, as well as possibly the jam_group and jam_role configurations. In any case, be advised that things may be messy for a week or two. -- Ryan 03-Oct-2008 22:21 PDT

With revision 2385 the major database changes needed to fully utilize Spring Security should be done now, and the next step is to add a filter to automatically create a jam_user record if a valid credential is available from an external system such as LDAP or OpenID. Once that's complete the Security changes should be done and integrating with LDAP, OpenID or other systems should be a much simpler process that utilizes the default Spring Security integration modules rather than custom JAMWiki code. -- Ryan 02-Nov-2008 17:24 PST
Thank you for investigating so much time in this feature. I think it is an VERY important one, at least in enterprise environment. Could you estimate the time left for release 0.7? br --hp 17-Nov-2008 07:29 PST
JAMWiki development has slowed down considerably lately due to increased demands from my day job, so it may be a while before the new code is completely ready. At this point I think all of the required database changes are done, but a Spring Security filter still needs to be created so that if a user is authenticated via a third-party system (such as LDAP or OpenID) then the necessary JAMWiki database records will be automatically created. Once that's done the remaining tasks consist mostly of testing and validation... I'm notoriously bad at estimating release dates, but I would be surprised if this release was finished before the end of the year and suspect that something in the January to February timeframe is probably more realistic (could be December, or it could drag into March/April, but I suspect January/February). I realize that it's a LONG release cycle, but this was a big change and I'd like to make sure it only has to be done once, and not re-visited again in the future. -- Ryan 17-Nov-2008 08:39 PST

[Edit]Update November 2008

I've had almost no time this month to devote to JAMWiki development so not much has changed, although the code was extensively updated in October with new database schemas, filter updates, etc. As of tonight jamwiki.org is now running the latest code with all of the database and Spring Security changes, so any problem reports (unable to login, problems changing account info, etc) would be much appreciated. -- Ryan 23-Nov-2008 20:07 PST

[Edit]Update January 2009

The JAMWiki Subversion repository now contains code that will accept an LDAP authentication object and automatically create the necessary JAMWiki database records to match that object, if needed. At this point all of the major goals for the 0.7.x security updates are done, although the following are on the nice-to-have list (some of these, particularly documentation updates, will definitely be done for 0.7.0):

  • Simplify configuration further.
  • Either remove all traces of the old JAMWiki LDAP configuration code, or else create a JAMWiki LDAP module that can be used to configure LDAP from the Special:Admin page. I'm leaning towards getting rid of the old code and relying solely on Spring Security configuration, so if anyone has an opinion please share.
I would also remove the old LDAP-Code - one option for configuring LDAP should be sufficient. --hp 06-Jan-2009 02:35 PST
  • Create documentation.
  • Determine whether or not to automatically apply the ROLE_USER permissions to users authenticated via LDAP. If this isn't done then update Special:Roles to indicate that those permissions will only apply to non-LDAP setups.

After I've had a bit more time to test the new code locally I'll roll it out to jamwiki.org. Comments and questions are encouraged for those interested in this development. -- Ryan 04-Jan-2009 15:35 PST

jamwiki.org is now running the latest code. I've been running this code locally for a while and haven't seen issues, and provided there aren't any problems on jamwiki.org then it will be time to push the first 0.7.0 beta release. I've also removed all traces of the old LDAP code - while I would like to have tighter integration with the existing JAMWiki configuration interface I think it might be confusing to mix Spring Security configuration with JAMWiki configuration. -- Ryan • (comments) • 10-Jan-2009 19:20 PST