You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-users@xml.apache.org by Steven Cummings <cu...@netscape.net> on 2003/01/28 17:09:09 UTC
Security question (or proposal) for the developers...
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: cummingscs@netscape.net
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/
Re: string compare operators not working?
Posted by Terry Rosenbaum <Te...@amicas.com>.
You can't compare strings using the operators that
have ">" or "<" in them. That's explained in the
XPath standard (http://www.w3.org/TR/xpath).
/"When neither object to be compared is a node-set and the *operator* is
|=| or |!=|,
then the objects are compared by converting them to a common type as follows
and then comparing them. ..."/
Thus "=" works.
But,
/"When neither object to be compared is a node-set and the *operator* is
|<=|, |<|, |>=| or |>|,
then the objects are compared by converting both objects to numbers and
comparing
the numbers according to IEEE 754. ..."/
Since the conversion(s) fail, the comparison returns false.
Lexicographic comparison of strings is not supported for the
<, >, <=, and >= operators!
The behavior you see is consistent with the standard and is
not a bug.
-Terry
Jonathan Mark wrote:
>I am running into the following issue using Xindice from CVS:
>(my xalan file is xalan-2.4.0.jar).
>
>The operators <= >= > and < seem to always return false when applied to
>strings.
>For example if I add ["abc"<="abc"] to the end of an xpath query which
>returned some results, it now returns no results.
>An example of a failing query is:
>/db:datebook/db:category/db:date[string(db:start) = "2000-06-23 09:00"]["abc"<="abc"]
>
>The = operator works as expected, and the inequalities work as expected if
>applied to numbers rather than strings.
>(So appending ["abc"="abc"] or [5<=5] has no effect on the query result.)
>I have checked that the "<" and ">" signs are being quoted correctly when
>passed to the Xindice server over XML/RPC.
>
>Should I put this in bugzilla ... if so, for Xindice or Xalan?
>Or is it a known problem, or am I misunderstanding how it's supposed to
>work?
>
>many thanks,
>
> Jonathan Mark
>
>
>
string compare operators not working?
Posted by Jonathan Mark <jh...@xenops.com>.
I am running into the following issue using Xindice from CVS:
(my xalan file is xalan-2.4.0.jar).
The operators <= >= > and < seem to always return false when applied to
strings.
For example if I add ["abc"<="abc"] to the end of an xpath query which
returned some results, it now returns no results.
An example of a failing query is:
/db:datebook/db:category/db:date[string(db:start) = "2000-06-23 09:00"]["abc"<="abc"]
The = operator works as expected, and the inequalities work as expected if
applied to numbers rather than strings.
(So appending ["abc"="abc"] or [5<=5] has no effect on the query result.)
I have checked that the "<" and ">" signs are being quoted correctly when
passed to the Xindice server over XML/RPC.
Should I put this in bugzilla ... if so, for Xindice or Xalan?
Or is it a known problem, or am I misunderstanding how it's supposed to
work?
many thanks,
Jonathan Mark
Re: Security question (or proposal) for the developers...
Posted by Emiliano <em...@iris-advies.nl>.
On Thu, Jan 30, 2003 at 01:46:28AM +0000, moran@server.jce.ac.il wrote:
> 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?
I can understand leaving authentication and authorization out of the
core, but I too find it puzzling that the default method of accessing
collections in that case isn't the embedded mode. If that were the case,
you could indeed limit access to the database, as long as you trust code
running in the same VM (which could be an issue in a servlet context, I
guess).
The default setup does not allow you to limit access at all, unless you
consider a firewall between Xindice and the rest of the world enough.
Emile
Re: Security question (or proposal) for the developers...
Posted by mo...@server.jce.ac.il.
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 <cu...@netscape.net>:
> 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: cummingscs@netscape.net
> 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
Documentation
Posted by Alex Mariano <ma...@inf.ufsc.br>.
Does anybody have a more updated version of guide-internals.pdf or some
other Xindice Documentation?
Alex Mariano
Re: Security question (or proposal) for the developers...
Posted by Gianugo Rabellino <gi...@apache.org>.
Steven Cummings wrote:
> Hello,
>
> I've been thinking about implementing security for Xindice lately,
>
<snip reason="agreed"/>
> Does anyone have any comments about this idea? Is it possible? Is it plausible? Is it desired?
You are most welcome to continue this discussion on the dev list, where
shortly we will tackle the challenge of starting the next version of
Xindice, where security will play for sure a key role.
For now, you might want to take a look into scratchpad, where there is
an ongoing JAAS oriented effort to come up with a viable security model.
Hope to see you there.
Ciao,
--
Gianugo Rabellino
CTO
Pro-netics s.r.l.
http://www.pro-netics.com