Chad, I am also very interested in getting at least minimal security running in Xindice and would be willing to give you a hand with this if you would like. Could you send me a copy of what you have to date, I would very much like to review it.
Thanks, Joel Chad La Joie wrote: > I've been working on a security model for Xindice and I wanted to run it by > everyone to see what they thought. > > First the goals I was trying to accomplish are follows: > 1. Create one centralized spot to ask if a user has certain rights. > 2. Allow for the following rights to be given to a person: Create/Remove > Collections Create/Remove/Execute XMLObjects, Create/Remove Indexes, > Query/Create/Update/Remove Documents. > 3. Provide a means to authenticate a user. > 4. Be thread safe. > 5. Be fast. > > Given that I came up with following architecture. > > 1. A SecurityManager will be used to as the centralized point for > permission inquiries and changes. > 2. A Person (will most likely change the name to User) class will model a > person's permissions. Inside that Person object will be a list of > CollectionPermission objects. These model a person's access to a specific > collection. Basically the operations listed in item 2 above which are not > collection specific are reflected in the Person object, those that are are > reflected in the CollectionPermission object. > 3. The SecurityManager provides authenticateUser and deauthenticateUser > methods. Before the manager can query some one's credentials the user must > be authenticated, starting their "session" (note: there is no real concept > of a session as in a transactional session). The user must then be > deauthenticated (logged-out) after they are done. The authenticate process > is done by passing the manager a userid/password pair. > 4. The SecurityManager will be a singleton and will be 100% thread > safe. Very little state is kept in any of the object's proposed, those > that do keep state will ensure that access to those fields are controlled. > 5. For speed the manager will keep all currently authenticated user's > information in memory. > > It's a very simple architecture and borrows heavily on what is currently > org.dbxml.core.security. The major change is that each possible permission > check has it's own methods (for instance canCreateCollection). I chose > this as opposed to the current way simply for readability and ease in > programming. > > I'd be happy to send those interested in reviewing this the actual > interfaces and classes that I have done (note that no real code has been > written yet). I would however like to get some feedback in general for > what people think of the design. Does it sound better, worse, or just > different then the current design? > > Chad La Joie "It is true that you never know what > Middleware Services you have until it is gone, but it is also > IS&C - Virginia Tech true that you never know what you've > been missing until it > arrives."
begin:vcard n:Rosi-Schwartz;Joel tel;fax:+44 1435 831011 tel;home:+44 1435 831010 tel;work:+44 1435 831010 x-mozilla-html:TRUE org:Techne Research Limited version:2.1 email;internet:[EMAIL PROTECTED] title:Architect adr;quoted-printable:;;Downgate Farmhouse=0D=0AFurnace Lane;Warbleton near Heathfield;East Sussex;TN21 9AZ;United Kingdom fn:Joel Rosi-Schwartz end:vcard
