+1 for the progressive approach. This outline is a great plan. To start with high granularity would be asking for trouble, and be tons of work. I mean, it's going to be a lot of work anyway. But I like the idea of no access/RO access/RW access. If this could be done for top-level databases, that's 100% ahead of where it is now. Granularity can come later, if necessary (my guess is that that will introduce serious performance issues and greatly complicate the querying mechanisms).
Jim
At 10:49 AM 12/3/2002 +0100, you wrote:
Marc Molinari wrote:
(note: I kept the cross-post, but please, please, if you're interested in this subject please follow up on -dev)
There are pre-defined collections in /db/system which come installed with Xindice - called SysAccess, SysGroups, SysObjects, SysConfig, SysUsers and SysSymbols - and I wonder if I have just overlooked the documentation on these or if there isn't any.
ATM there is no AAA at all in Xindice. But it's planned and in a top position on my very personal to do list.
-> Has anyone experience with defining user/machine level access for Xindice (maybe in relation to the Apache XML Security project) and would be able to share this with the xindice community?
That would be very welcome.
-> Are there any plans for security features on the roadmap for future versions?
There was an RT from me talking (also) about security a short time ago (http://marc.theaimsgroup.com/?t=103839556100006&r=1&w=2&n=33), but we need to talk more about this subject.
Basically, what I would like to see is a progressive approach. We need basic security first, with a more sophisticated model to follow. The problem, as always, is in the authorization part. My (very personal) plan is the following:
1. define a basic ro/rw capability so that users might be defined with that kind of access, which will be at first database-wide (but at least we would begin to separate ro/rw users). This can be done easily in a hackish way in the beginning but we have to come up with a solid architecture first.
2. map that model to the collection, so that aaa can be specified at a collection level. Here we'll have the "cascade" problem: if I'm authorized to read /db/something am I automatically entitled to read /db/something/else/?
3. consider if it's overkill (and IMHO it is) to be even more granular, permitting to map aaa roles to documents in collections or even nodes.
-> Can I help?
Definitely, it would be very appreciated. Yes, we are hiring. :-)
Ciao,
-- Gianugo Rabellino
-- [EMAIL PROTECTED]
Visit www.jbrix.org for: + SpeedJAVA jEdit Code Completion Plugin + Xybrix XML Application Framework + other great Open Source Software
