Re: Xindice security (follow-up from xindice-dev: more access control thoughts)

[Jim Wissner <ji...@jbrix.org>]

+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

--
jim@jbrix.org

Visit www.jbrix.org for:
   + SpeedJAVA jEdit Code Completion Plugin
   + Xybrix XML Application Framework
   + other great Open Source Software