Hi, I have already posted here about authentication, and I find it troubling to here the words "easily enough" when, and I quote: "Authentication and encryption are left to the programmer..."
Let there be a malicious user who knows you are using Xindice. He can easily access all your xindic collections through the simple API. There is no guarantee that the data will not be traversed by another java application. How is it "easily enough" for the programmer to limit access? I know there are plans to make a collection with authentication, maybe sub-collections as well. But how can you dismiss this ? Am I missing something? Thank you, Moran. Quoting Steven Cummings <[EMAIL PROTECTED]>: > Hello, > > I've been thinking about implementing security for Xindice lately, about how > developers must mostly do it themselves. For the most part, this is done > fairly easily as it is based on the application at hand. But one particular > issue comes to mind. > > Most security packages have two or three main components: authentication > (system or subsystem entry), authorization (allowed operations on specified > entities or "subjects") and optionally some encryption of some sort. > Authentication and encryption are left to the programmer (Xindice user) > easily enough, but there is an abstract "issue" with authorization. > Authorizing operations depends mainly on the way they're defined in the > application. But what if one wants to authorize XUpdate commands to provide > the user of the application or web-service maximum flexibility of system use? > The inherent problem here is that the XUpdate commands have to be parsed and > interpreted by the application authorization code apart from being parsed and > executed by the XUpdate code (Lexus). If the rest of my system authorizes > reads, writes, creates, and deletes (all simple enough), then I would have to > parse the XUpdate and write my own code that sort of does a "dry run" of the > XUpdates, checking the write, create, and delete permissions of the various > modifications, insertions, etc. within the context of each operation. So my > question (or proposal?) is this, why not have Xindice provide a security > callback API where handlers can be registered with the database client (the > code using the standard XML:DB database object) or (the better option) the > server core (the code running the implementation-specific database -- > o.a.x.core.Database). These handlers could implement methods that signal that > a create or drop collection is about to occur, or document insert, update, > removal, or read. And of course, the methods could also signal the > operations that are allowed in the XUpdate API. The methods could be kind of > like the mutators of constrained javabean properties, the operation is > "vetoed" if it is not permissable by your application-specific authorization > code, which for example checks some security policy, and implements this > hypothetical handler API, much in the same way AXIS has handlers. As I said > before, all of these things c > an pretty much already be done, except that particularly with XUpdates, a lot > of extra and akward code has to be managed (the dry runs of the updates). > > Does anyone have any comments about this idea? Is it possible? Is it > plausible? Is it desired? > > /S > -- > Steven Cummings > Columbia, MO > Email: [EMAIL PROTECTED] > AIM: cummingscs > ICQ: 3330114 > > > __________________________________________________________________ > The NEW Netscape 7.0 browser is now available. Upgrade now! > http://channels.netscape.com/ns/browsers/download.jsp > > Get your own FREE, personal Netscape Mail account today at > http://webmail.netscape.com/ > ------------------------------------------------- This mail sent through JCE IMP: http://portal.jce.ac.il/horde/ Main Web Page http://www.jce.ac.il
