You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Jim Wissner <ji...@jbrix.org> on 2002/11/07 00:30:20 UTC
more access control thoughts (long)
Hello,
I've been giving some more thought to the concept of user access control.
Actually quite a bit of thought. My interest with regards to this topic is
in using Xindice as the primary data storage mechanism for an open-source
web application framework that I'm developing.
In addition to a web front-end, I would like ideally to allow the content
generated by users through the web to also be to accessible to them through
other non-browser applications. To that end I've been working on the SOAP
interface to Xindice, which has been going quite well (I have some updates
to it by the way if anyone is interested).
But fairly quickly it becomes evident that moving from the prototype stage
to the delivery stage is impeded by a lack of access control. Users
obviously shouldn't be able to access things that aren't meant for them.
So the question is, and I fully appreciate the limitations of resources and
that there is much important work elsewhere in the project, is there any
sort of game plan in this regard? I've searched through the list archives
and found some good discussions about this matter, but nothing recent, and
they seem to raise more questions than answers. Clearly this is not a
trivial issue.
However since it seems to me that there is enormous power in Xindice as a
web-services-enabled XML database, finding the answer to this could
possibly open up the range of adopters. Or, more specifically, I think NOT
having an answer is going to eliminate a large number of potential adopters
who don't have the right resources (time, developers, etc) to implement it
themselves.
Now, I realize that:
- I'm stating the obvious
- There are many other outstanding issues
- It's not a simple problem
- Xindice is an open source project with it's OWN resource constraints
I'm also very conscious of the fact that I'm relatively new to the project
and the mailing list, and being a lead developer in other open source
projects, I understand the sensitivity to new people coming in and stating
"I need this, that and the other thing, and Oh, by the way, fix these bugs
too." :)
So all that being said, I would like to solicit any opinions about a few
assumptions and ideas that I'm starting to work through in hopes of
possibly moving forward.
- Fact: I need an XML database. No surprise; why else would I be here? :)
- Fact: Having looked at many, and worked with a few, I REALLY like Xindice.
- Assumption: there is little-to-no time for the key developers of Xindice
to begin to devote substantial time to this part of the API
- Assumption: there is agreement at least at the most basic level that user
access control, if not necessary, would at least make a compelling addition
to the project.
Given this, if I were to devote some time to start attacking this problem,
I believe I would start with the following basic goal:
The solution should have minimum-to-zero impact on the rest of the
development. This is obvious since I wouldn't expect as an "outsider" to be
allowed to make changes to the core. It will also however restrict the form
of the solution. Basically the only real possibility is a "wrapper" that
gates all access to the database. For instance, my SOAP servlet could
require authorization before fulfilling requests.
One problem with this solution is that if access is provided through
another means, say for instance the xml-rpc servlet, then the authorization
scheme may as well not exist at all since it is then defeated. Now given
that, as I have recently learned, only one Database instance is allowed
(which incidentally is a fact that brings about its own problems once there
is talk about having multiple servlets available), we can possibly assume
that a deployment will only allow access through one mechanism. (Is this
true?) Or, better yet, the database instance and also the authorization
mechanisms could be implemented in a base XindiceServlet class and thus
inherited and utilized by all servlet subclasses (soap, xml-rpc,
etc). Then we just hope someone doesn't access it through the xml:db API! :)
This non-disruptive (wrt core development, that is) approach could be
recast as a "minimally disruptive" approach by implementing the access
control in the Database class, and requiring authorization to root-level
collections.
It is clear that another problem with the wrapper approach is that it is
difficult to provide granular control. Other people on the list have
proposed solutions for granular access control, and of course they are much
more work, but give more flexibility.
I haven't touched upon the issue of raw data security - this is something
that can be implemented somewhat independently, through SSL, end-point
encryption/decryption, or something else. Having worked in the health care
industry I realize the importance of this in some segments, but I think
it's more easily resolvable than access control, and lower on the priority
list of app developers who may go the Xindice route.
If anyone has any comments I would be happy to hear them. The bottom line
for me is that I'm going to have to devote at least some amount of time to
some form of user authentication and access control, however complex or
simple it might be. I would be happy to do this at the Xindice level, if I
find encouragement. If not then I will have to treat Xindice as a
black-box around which my application framework allows no other access,
which wouldn't be my first choice.
Thanks, and sorry for the long-windedness. :)
Jim
--
jim@jbrix.org
Visit www.jbrix.org for:
+ SpeedJAVA jEdit Code Completion Plugin
+ Xybrix XML Application Framework
+ other great Open Source Software
RE: more access control thoughts (long)
Posted by Jim Wissner <ji...@jbrix.org>.
At 09:48 PM 11/7/2002 +1100, you wrote:
>It would be interesting to see how other people are using Xindice and
>how that impacts the possible security options. Is it being used in most
>places as a server with various clients talking to it? Or are there
>other folks that are looking to use an xml store similarly to us -
>inside apps and not having any remote/server access to the store?
>
>peter w.
Your comments were interesting to read... On this last point, I would
rephrase the question from "how IS it being used" to "how COULD it be
used". My belief still is that a whole new audience would open up once
these specific issues are tackled.
Of course now I can see that most people (at least those that have spoken
up) generally confirmed a desire for user management, the question is how
to get there.... This is the tricky part! ;)
Jim
--
jim@jbrix.org
Visit www.jbrix.org for:
+ SpeedJAVA jEdit Code Completion Plugin
+ Xybrix XML Application Framework
+ other great Open Source Software
Re: more access control thoughts (long)
Posted by Jim Wissner <ji...@jbrix.org>.
On the issue of multiple "entry points," I was thinking about the idea of a
single base class brokering access to a database instance. But this of
course doesn't mean that two servlets can't get ahold of the same
collection, hold on to the collection handle after the database is
"released", and then work with the collection simultaneously from different
threads. This again raises the issue of thread safety (as opposed to just
the question of is it ok to have more than one database instance).
Are there any thread safety plans? I searched the list and saw some
questions but no specific answers. I ask this not as another thing to be
done, but it will certainly affect the tactics used for short-term
solutions to the multiple servlet issue.
Jim
At 01:23 AM 11/7/2002 -0500, you wrote:
>Jim,
>
>Your train of thought is certainly inline with what we would like to
>implement
>into Xindice. It is a problem with the current codebase and needs to be a
>top
>priority for future releases. The SOAP client and servlet you have written
>are
>VERY important and useful for the project, and I would like to see it in the
>CVS tree.
>I am thinking that maybe an install script of some sort or servlet/jsp needs
>to be created to specify
>what db access method is exposed with configurable endpoints. Personally, I
>use the XML-RPC interface, but I think it should either be configurable or
>like you mentioned stemmed from the initial servlet for multiple access
>methods (well, vice XML:DB - and I don't know much about that).
>
>Kurt
>
>----- Original Message -----
>From: "Jim Wissner" <ji...@jbrix.org>
>To: <xi...@xml.apache.org>
>Sent: Wednesday, November 06, 2002 6:30 PM
>Subject: more access control thoughts (long)
>
>
> >
> > Hello,
> >
> > I've been giving some more thought to the concept of user access control.
> > Actually quite a bit of thought. My interest with regards to this topic is
> > in using Xindice as the primary data storage mechanism for an open-source
> > web application framework that I'm developing.
> >
> > In addition to a web front-end, I would like ideally to allow the content
> > generated by users through the web to also be to accessible to them
>through
> > other non-browser applications. To that end I've been working on the SOAP
> > interface to Xindice, which has been going quite well (I have some updates
> > to it by the way if anyone is interested).
> >
> > But fairly quickly it becomes evident that moving from the prototype stage
> > to the delivery stage is impeded by a lack of access control. Users
> > obviously shouldn't be able to access things that aren't meant for them.
> >
> > So the question is, and I fully appreciate the limitations of resources
>and
> > that there is much important work elsewhere in the project, is there any
> > sort of game plan in this regard? I've searched through the list archives
> > and found some good discussions about this matter, but nothing recent, and
> > they seem to raise more questions than answers. Clearly this is not a
> > trivial issue.
> >
> > However since it seems to me that there is enormous power in Xindice as a
> > web-services-enabled XML database, finding the answer to this could
> > possibly open up the range of adopters. Or, more specifically, I think
>NOT
> > having an answer is going to eliminate a large number of potential
>adopters
> > who don't have the right resources (time, developers, etc) to implement it
> > themselves.
> >
> > Now, I realize that:
> >
> > - I'm stating the obvious
> > - There are many other outstanding issues
> > - It's not a simple problem
> > - Xindice is an open source project with it's OWN resource
>constraints
> >
> > I'm also very conscious of the fact that I'm relatively new to the project
> > and the mailing list, and being a lead developer in other open source
> > projects, I understand the sensitivity to new people coming in and stating
> > "I need this, that and the other thing, and Oh, by the way, fix these bugs
> > too." :)
> >
> > So all that being said, I would like to solicit any opinions about a few
> > assumptions and ideas that I'm starting to work through in hopes of
> > possibly moving forward.
> >
> > - Fact: I need an XML database. No surprise; why else would I be here?
>:)
> > - Fact: Having looked at many, and worked with a few, I REALLY like
>Xindice.
> > - Assumption: there is little-to-no time for the key developers of Xindice
> > to begin to devote substantial time to this part of the API
> > - Assumption: there is agreement at least at the most basic level that
>user
> > access control, if not necessary, would at least make a compelling
>addition
> > to the project.
> >
> > Given this, if I were to devote some time to start attacking this problem,
> > I believe I would start with the following basic goal:
> >
> > The solution should have minimum-to-zero impact on the rest of the
> > development. This is obvious since I wouldn't expect as an "outsider" to
>be
> > allowed to make changes to the core. It will also however restrict the
>form
> > of the solution. Basically the only real possibility is a "wrapper" that
> > gates all access to the database. For instance, my SOAP servlet could
> > require authorization before fulfilling requests.
> >
> > One problem with this solution is that if access is provided through
> > another means, say for instance the xml-rpc servlet, then the
>authorization
> > scheme may as well not exist at all since it is then defeated. Now given
> > that, as I have recently learned, only one Database instance is allowed
> > (which incidentally is a fact that brings about its own problems once
>there
> > is talk about having multiple servlets available), we can possibly assume
> > that a deployment will only allow access through one mechanism. (Is this
> > true?) Or, better yet, the database instance and also the authorization
> > mechanisms could be implemented in a base XindiceServlet class and thus
> > inherited and utilized by all servlet subclasses (soap, xml-rpc,
> > etc). Then we just hope someone doesn't access it through the xml:db API!
>:)
> >
> > This non-disruptive (wrt core development, that is) approach could be
> > recast as a "minimally disruptive" approach by implementing the access
> > control in the Database class, and requiring authorization to root-level
> > collections.
> >
> > It is clear that another problem with the wrapper approach is that it is
> > difficult to provide granular control. Other people on the list have
> > proposed solutions for granular access control, and of course they are
>much
> > more work, but give more flexibility.
> >
> > I haven't touched upon the issue of raw data security - this is something
> > that can be implemented somewhat independently, through SSL, end-point
> > encryption/decryption, or something else. Having worked in the health care
> > industry I realize the importance of this in some segments, but I think
> > it's more easily resolvable than access control, and lower on the priority
> > list of app developers who may go the Xindice route.
> >
> > If anyone has any comments I would be happy to hear them. The bottom line
> > for me is that I'm going to have to devote at least some amount of time to
> > some form of user authentication and access control, however complex or
> > simple it might be. I would be happy to do this at the Xindice level, if I
> > find encouragement. If not then I will have to treat Xindice as a
> > black-box around which my application framework allows no other access,
> > which wouldn't be my first choice.
> >
> > Thanks, and sorry for the long-windedness. :)
> >
> > Jim
> >
> >
> > --
> > jim@jbrix.org
> >
> > Visit www.jbrix.org for:
> > + SpeedJAVA jEdit Code Completion Plugin
> > + Xybrix XML Application Framework
> > + other great Open Source Software
--
jim@jbrix.org
Visit www.jbrix.org for:
+ SpeedJAVA jEdit Code Completion Plugin
+ Xybrix XML Application Framework
+ other great Open Source Software
Re: more access control thoughts (long)
Posted by Kurt Ward <ku...@yahoo.com>.
Jim,
Your train of thought is certainly inline with what we would like to
implement
into Xindice. It is a problem with the current codebase and needs to be a
top
priority for future releases. The SOAP client and servlet you have written
are
VERY important and useful for the project, and I would like to see it in the
CVS tree.
I am thinking that maybe an install script of some sort or servlet/jsp needs
to be created to specify
what db access method is exposed with configurable endpoints. Personally, I
use the XML-RPC interface, but I think it should either be configurable or
like you mentioned stemmed from the initial servlet for multiple access
methods (well, vice XML:DB - and I don't know much about that).
Kurt
----- Original Message -----
From: "Jim Wissner" <ji...@jbrix.org>
To: <xi...@xml.apache.org>
Sent: Wednesday, November 06, 2002 6:30 PM
Subject: more access control thoughts (long)
>
> Hello,
>
> I've been giving some more thought to the concept of user access control.
> Actually quite a bit of thought. My interest with regards to this topic is
> in using Xindice as the primary data storage mechanism for an open-source
> web application framework that I'm developing.
>
> In addition to a web front-end, I would like ideally to allow the content
> generated by users through the web to also be to accessible to them
through
> other non-browser applications. To that end I've been working on the SOAP
> interface to Xindice, which has been going quite well (I have some updates
> to it by the way if anyone is interested).
>
> But fairly quickly it becomes evident that moving from the prototype stage
> to the delivery stage is impeded by a lack of access control. Users
> obviously shouldn't be able to access things that aren't meant for them.
>
> So the question is, and I fully appreciate the limitations of resources
and
> that there is much important work elsewhere in the project, is there any
> sort of game plan in this regard? I've searched through the list archives
> and found some good discussions about this matter, but nothing recent, and
> they seem to raise more questions than answers. Clearly this is not a
> trivial issue.
>
> However since it seems to me that there is enormous power in Xindice as a
> web-services-enabled XML database, finding the answer to this could
> possibly open up the range of adopters. Or, more specifically, I think
NOT
> having an answer is going to eliminate a large number of potential
adopters
> who don't have the right resources (time, developers, etc) to implement it
> themselves.
>
> Now, I realize that:
>
> - I'm stating the obvious
> - There are many other outstanding issues
> - It's not a simple problem
> - Xindice is an open source project with it's OWN resource
constraints
>
> I'm also very conscious of the fact that I'm relatively new to the project
> and the mailing list, and being a lead developer in other open source
> projects, I understand the sensitivity to new people coming in and stating
> "I need this, that and the other thing, and Oh, by the way, fix these bugs
> too." :)
>
> So all that being said, I would like to solicit any opinions about a few
> assumptions and ideas that I'm starting to work through in hopes of
> possibly moving forward.
>
> - Fact: I need an XML database. No surprise; why else would I be here?
:)
> - Fact: Having looked at many, and worked with a few, I REALLY like
Xindice.
> - Assumption: there is little-to-no time for the key developers of Xindice
> to begin to devote substantial time to this part of the API
> - Assumption: there is agreement at least at the most basic level that
user
> access control, if not necessary, would at least make a compelling
addition
> to the project.
>
> Given this, if I were to devote some time to start attacking this problem,
> I believe I would start with the following basic goal:
>
> The solution should have minimum-to-zero impact on the rest of the
> development. This is obvious since I wouldn't expect as an "outsider" to
be
> allowed to make changes to the core. It will also however restrict the
form
> of the solution. Basically the only real possibility is a "wrapper" that
> gates all access to the database. For instance, my SOAP servlet could
> require authorization before fulfilling requests.
>
> One problem with this solution is that if access is provided through
> another means, say for instance the xml-rpc servlet, then the
authorization
> scheme may as well not exist at all since it is then defeated. Now given
> that, as I have recently learned, only one Database instance is allowed
> (which incidentally is a fact that brings about its own problems once
there
> is talk about having multiple servlets available), we can possibly assume
> that a deployment will only allow access through one mechanism. (Is this
> true?) Or, better yet, the database instance and also the authorization
> mechanisms could be implemented in a base XindiceServlet class and thus
> inherited and utilized by all servlet subclasses (soap, xml-rpc,
> etc). Then we just hope someone doesn't access it through the xml:db API!
:)
>
> This non-disruptive (wrt core development, that is) approach could be
> recast as a "minimally disruptive" approach by implementing the access
> control in the Database class, and requiring authorization to root-level
> collections.
>
> It is clear that another problem with the wrapper approach is that it is
> difficult to provide granular control. Other people on the list have
> proposed solutions for granular access control, and of course they are
much
> more work, but give more flexibility.
>
> I haven't touched upon the issue of raw data security - this is something
> that can be implemented somewhat independently, through SSL, end-point
> encryption/decryption, or something else. Having worked in the health care
> industry I realize the importance of this in some segments, but I think
> it's more easily resolvable than access control, and lower on the priority
> list of app developers who may go the Xindice route.
>
> If anyone has any comments I would be happy to hear them. The bottom line
> for me is that I'm going to have to devote at least some amount of time to
> some form of user authentication and access control, however complex or
> simple it might be. I would be happy to do this at the Xindice level, if I
> find encouragement. If not then I will have to treat Xindice as a
> black-box around which my application framework allows no other access,
> which wouldn't be my first choice.
>
> Thanks, and sorry for the long-windedness. :)
>
> Jim
>
>
> --
> jim@jbrix.org
>
> Visit www.jbrix.org for:
> + SpeedJAVA jEdit Code Completion Plugin
> + Xybrix XML Application Framework
> + other great Open Source Software
Re: more access control thoughts (long)
Posted by "Vladimir R. Bossicard" <vl...@bossicard.com>.
Quick note:
go ahead and modify the core code if you have to. If you do a search
with 'todo' you'll find several place where authentification is needed.
So don't be shy and other people will certainly be interested in helping
you.
-Vladimir
--
Vladimir R. Bossicard
www.bossicard.com
Re: New Xindice Admin
Posted by Kurt Ward <ku...@yahoo.com>.
It's in the scratchpad. There is no Ant build for it and there are several
flaws at the moment, for example
as a quick hack to get it talking to the database, each command is creating
it's own XML-RPC client. Most of the commands are empty and do nothing but
echo the command until we figure out which access method would be best.
There is a built in script runner that will execute script files along with
a test script (test.scr).
Kurt
----- Original Message -----
From: "Vladimir R. Bossicard" <vl...@bossicard.com>
To: <xi...@xml.apache.org>
Sent: Thursday, November 07, 2002 4:50 AM
Subject: Re: New Xindice Admin
> > The framework is pretty close to adding to CVS (or at least the
scratchpad).
>
> Can you commit your code to the scratchpad? The goal of this folder is
> to contain unfinished code that may interest other people.
>
> If everybody works alone, work will be duplicated.
>
> -Vladimir
>
> --
> Vladimir R. Bossicard
> www.bossicard.com
Re: New Xindice Admin
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
how about:
/src/java/ui.eclipse?
--Kevin
Vladimir R. Bossicard wrote:
>> Any thoughts on location?
>
>
> scratchpad would be a good location in the meantime. I think that the
> location should be outside the core tree and we should have one folder
> per project. In the current tree, "java/eclipse" should be fine.
>
> But we could also start moving code around and using the "src" folder.
>
> -Vladimir
>
Re: New Xindice Admin
Posted by "Vladimir R. Bossicard" <vl...@bossicard.com>.
> Any thoughts on location?
scratchpad would be a good location in the meantime. I think that the
location should be outside the core tree and we should have one folder
per project. In the current tree, "java/eclipse" should be fine.
But we could also start moving code around and using the "src" folder.
-Vladimir
--
Vladimir R. Bossicard
www.bossicard.com
RE: New Xindice Admin
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
I'm also planning on committing the Eclipse UI somewhere, but haven't
looked into this yet. I still have to submit a formal request for the
donation to the very willing Rosi-Schwartz(s).
Any thoughts on location?
This will have particular dependencies outside the realm of our usual
java development.
-Kevin
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@bossicard.com]
Sent: Thursday, November 07, 2002 3:50 AM
To: xindice-dev@xml.apache.org
Subject: Re: New Xindice Admin
> The framework is pretty close to adding to CVS (or at least the
scratchpad).
Can you commit your code to the scratchpad? The goal of this folder is
to contain unfinished code that may interest other people.
If everybody works alone, work will be duplicated.
-Vladimir
--
Vladimir R. Bossicard
www.bossicard.com
Re: New Xindice Admin
Posted by "Vladimir R. Bossicard" <vl...@bossicard.com>.
> The framework is pretty close to adding to CVS (or at least the scratchpad).
Can you commit your code to the scratchpad? The goal of this folder is
to contain unfinished code that may interest other people.
If everybody works alone, work will be duplicated.
-Vladimir
--
Vladimir R. Bossicard
www.bossicard.com
New Xindice Admin
Posted by Kurt Ward <ku...@yahoo.com>.
All,
I have been working on a new interactive command line interface for Xindice
that is similar to the MySQL command line interface. The framework is
pretty close to adding to CVS (or at least the scratchpad). Before I get
too much work done, I'm wondering if it should be based on a specific access
layer (currently XML-RPC), or if it should be XML:DB, or configurable.
Thoughts?
Kurt
RE: more access control thoughts (long)
Posted by pw...@thirdfloor.com.au.
> Subject: more access control thoughts (long)
>
Hi Jim,
We've been using Xindice for about a year in a number of different
applications and the question about security has come up many times.
In our use of Xindice it is largely accessed by a single app and
occasionally by the command line tools to do low level admin (app always
shut down) and our thinking of how to approach security comes from that.
We are really interested in embedding xindice inside our app more than
any kind of server type access to the datastore - one of the apps is a
GUI based one, i.e. preferably no server at all. We see the Xindice
store as just a file that our app will use that happens to have a very
sexy way of dealing with its contents. For this we are happy to just
use the base OS security to let us in or not to the data.
The major problem with this being concurrent access to the store so that
multiple processes that have permissions to the store don't mess each
other up. Being able to lock a portion of a collection or a whole
collection would be ideal for us - similar to lockf but based on
resource id in the collection rather than purely data length.
For times when Xindice is being used as a server your suggestion of
basing all servlets of a base XindiceServlet makes most sense to me. The
problem with other code getting at the data under the covers again
brings up the benefits of being able to lock portions of the store - if
we could do that there would be no need to worry.
I have to say that I'm largely ignorant as to the internals of Xindice
and so my comments about locking may be entirely misplaced and a major
reworking of the guts of Xindice may be required to support this. I
understand Java's lack of any support for locking until 1.4 may make
this more difficult.
It would be interesting to see how other people are using Xindice and
how that impacts the possible security options. Is it being used in most
places as a server with various clients talking to it? Or are there
other folks that are looking to use an xml store similarly to us -
inside apps and not having any remote/server access to the store?
peter w.