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
