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 can 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/
