Security Model

[Chad La Joie <cl...@vt.edu>]

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

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

Re: Security Model

[Kimbro Staken <ks...@dbxmlgroup.com>]

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/