Re: Security Model

[Joel Rosi-Schwartz <jo...@btconnect.com>]

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