Sorry for taking so long to reply to this.
On Sunday, January 20, 2002, at 03:02 PM, 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.
Will this be easily extensible? i.e. if we add triggers later how hard will it be to incorporate them in security?
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.
Ok, since I don't remember how the current system does this and it wasn't obvious from a quick scan it might be good if it clarifies things a bit. Just be aware that the current code does actually work(at least it did anyway), where I stopped was on tying it in to actually restrict access to resources. If there's a way to simplify and clarify what's going on to a significant degree then it's probably worth it, otherwise since your architecture is pretty similar anyway keeping the existing code might be easier.
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?
It seems OK, it'd be good if you could make what you have available via the web. If you don't have a place to post them, you can send them to me and I'll put it up somewhere.
Have you looked at how you would use this to actually lock down the system yet?
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."
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
