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 constraintsI'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
