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."