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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 > > > -- > [EMAIL PROTECTED] > > Visit www.jbrix.org for: > + SpeedJAVA jEdit Code Completion Plugin > + Xybrix XML Application Framework > + other great Open Source Software
-- [EMAIL PROTECTED]
Visit www.jbrix.org for: + SpeedJAVA jEdit Code Completion Plugin + Xybrix XML Application Framework + other great Open Source Software
