Using Acegi with Jakarta Slide

[adepue]

Hello all,
We are evaluating Slide as a content repository for our Spring + Acegi + Spring-rich based project. I'm wondering if anyone here has experience integrating Slide security with Acegi? Right now we manage all our security in a custom DB via our own service interfaces and provide Acegi an AuthenticationDao for integration. We would like Slide to retrieve all its knowledge about a user (principal, roles, etc) via Acegi - in other words, we don't want Slide to manage any user or user authentication information. In the end we would like to utilize Slide's security to secure content, but move authentication and user management out of Slide and into the realm of Acegi (+ our DAO).

Thanks,
Andy

[adepue]

I found this message by Ben Alex, no less, on gmane:
http://permalink.gmane.org/gmane.com...lide.user/4239
Couldn't find any responses to his message. Wonder if he actually implemented something that integrates with Slide? I did a quick search in my Acegi sources for "slide" and couldn't find anything.
I also found this useful message:
http://www.mail-archive.com/slide-us.../msg05881.html
From what Ben says here it looks like his integration with Slide only provides a user name, which means Slide is probably still managing its own copy of user roles? One thing I would really like to avoid is having to maintain two sets of roles for the same user (one in Slide and one for the rest of the system). I want to provide both the user and roles to Slide. Of course, Slide can still manage its own ACLs for various objects, just let me tell Slide which roles the user has.

- Andy

[Ben Alex]

Yes, I did get it to work, although I didn't approach the greater level of integration to which you refer. Have you considered using the Tomcat WebDav servlet? I only mention it as it is far simpler, and it relies solely on web.xml security. As such, it's probably far more amenable to having security enforced by Acegi Security. I was initially attracted to Slide due to its support for JDBC-based repositories, although, to be honest, I found them just too buggy to use at the time for our project. In the end I implemented my own content repository solution, with knowledge a WebDAV layer can be bolted on later if necessary.

[adepue]

Tomcat WebDAV isn't really an option for us: we need ACLs, versioning, and a DB based repository. We would like to go with Slide, though it would be an issue if it wasn't stable with DB repositories. Here's hoping they've been working on it since your experience. Of course, I could be mistaken about what features Tomcat WebDAV has built in, which would be nice.

- Andy

[adepue]

Looks like the Slide project has released a "WebDAV Construction Kit":
http://jakarta.apache.org/slide/wck.html

The WebDAV Construction Kit (WCK) is a framework for easy integration of the WebDAV interface into all kinds of Java software. No special knowledge of Slide or WebDAV is required to make the usual Windows, Mac and Linux clients work with your server system. These are the main features:

* adapter for Slide's complex storage mechanism to a simple API
* reference implementation and default configuration to a complete and simple file system store
* JAAS authentication framwork to completely bypass Slide's security mechanism; instead the user base and access rights of your server system is used
* generic pooling framwork for connections to your server system using commons pool
* build script that compiles WCK to both Slide 2.1 and the current Slide head

Looks like it's just what I need... if it works.

- Andy

[Ben Alex]

The WCK looks interesting. I notice it uses good old Principal objects, so hopefully we can just pass it an Authentication. I have to revisit web content repository management this week, so I'll check it out in more detail then...

[adepue]

Ben,
According to their site information WCK doesn't support ACLs (yet). I may have to end up interfacing directly with Slide after all. I'm curious, what bugs with JDBC store did you run into?

Thanks,
Andy

[Ben Alex]

It didn't gracefully handle large (>20 Mb) files uploaded via WebDav. I had to write my own implementation which used Postgres large objects. That fixed up the out of memory errors and slow performance.

Separately I ran into problems when executing searches, and property finds. Null pointer exceptions were frequent. In the end I decided to just write my own, as WebDav-specific compatibility was not important to my clients.

It would be nice if there were a Spring-specific WebDav implementation, with nice interfaces and IoC and Acegi Security integration. We certainly have the functionality already to do the ACL functions. Just need someone with a spare month. :-)

[adepue]

I wish I had a month to do such a thing. I've been studying the source in preparation for implementing my own principal store (to access my currently existing user/role DB), and from what I've seen Slide looks tightly coupled to its current config mechanism. However, I'm planning on borrowing the DAO idea from Acegi. I'm going to implement a DAOPrincipalStore that simply delegates to a simplified DAO. I think it will look something like this:

public interface PrincipalStoreDAO
{
  Collection getRoles();
  Collection getUsers(... some kind of Slide criteria ...)
  Collection getUsersWithRole(String roleName)
}
}

But don't quote me on that yet.
Slide is odd in that it does not directly lookup the roles a user has, but rather expects each role to list the users who have the role. So whenever it does a permission check it first gets the role, parses an XML formatted property on the role that contains the list of all users who have the role, and then iterates through the list to see if it contains the current user. Our system will eventually grow to having thousands of users with certain roles...
Slide completely controls the lifecycle of the Store, from what I can tell. So, I'm planning on somehow getting access to the Spring app context from within the Store so that the store can lookup the DAO from Spring. Not sure yet how the store is going to get the app context, though. Any ideas? The Store won't have access to a servlet context so that rules out WebApplicationContextUtils. I'd hate to have to use some static variable somewhere...

- Andy

[Ben Alex]

Hi Andy, I've replied off-list.