Re: access control in xindice

[Honglin Ye]

Murray Altheim wrote:
Honglin Ye wrote:
Murray Altheim wrote:

Honglin Ye wrote:
[...]

xml-security is a too-big topic. I am thinking how to prevent un-wanted
query. As it stands now, Any one who knows the hostName and portNumber
can query/update documents inside, by using either a commandline 
tool or
a slightly modified java-api. (assume that he is inside the 
firewall, or
he is outside firewall but the port used is open)

But you can do that in your application, not in Xindice. There's
no need to pollute Xindice's code base with every single need there
is out there. There's about ten ways to handle this before you ever
need to modify things at the database layer.
Murray

I did not demand to pollute xindice. While you mentioned ten ways to 
accomplish
that, I only need one. The easier the better. Can anyone let me how to 
hide
the xindice from quering using commandline tool?

excellent. Thanks for the solutions
These are just off the top of my head as I type them:
  1. write a small proxy to sit between the actual Xindice port and
     the proxy (public) port. This could probably be accomplished
     with less than a thousand lines of code (I wrote a tiny HTTP
     server in about 500-600).
if the person access the proxy port, the request will pass on to xindice port.
how this thing distinquish between a ok-user and a not-ok-user?
  2. create an IP access control list to filter access via incoming
     IP addresses
the authorized users are distributed over the world, I have no way of
knowing where that request comes from.
  3. use a user-based system:
      a. via username-password
      b. via domain-based filtering
same reason as above
  4. extend one or two of Xindice's classes to enable data flow based on
     any number of factors.
this is good, but if xindice changes, the extension has to follow
  5. use a cookie-based system (i.e., if the user query doesn't have
     the right cookie, deny service
good for web app, authenticate in app. commandline query not coverd
  6. encrypt all data stored in Xindice (prior to going into Xindice)
     and give the keys only to trusted clients
good solution, i only need to deliver the encrypting key and de-encrypting tool
to those users
  7. extend the client to require a preliminary handshaking, where
     the server challenges the client to produce a hash.
do you mean modify xindice's commandline tool?
  8. make the port available only within your LAN/WAN
the port is available inside, i need to hide docs from the people inside too.
  9. use existing proxies to keep out intruders
 10. require access only via a downloaded client that uses any number
     of secure methods to gain access to the server (hashes, passwords,
     etc.)
 11. alter the query itself to include a hash prefix. The formula
     to the hash is only known to you and trusted clients.
this may be the easiest solution. the hash prefix works like a password.
I dunno. This is five minutes' effort. I'm sure I could think of
more. I'm sure others could too.
Murray