xml-xindice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <m.alth...@open.ac.uk>
Subject Re: access control in xindice
Date Wed, 11 Feb 2004 17:04:38 GMT
Honglin Ye wrote:
> Murray Altheim wrote:
 >>>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?

Well, that's your job to do. There's probably a bunch of ways to do
this too. You could either build something simple from scratch or
use an existing system. There are quite a lot of available security
projects on SourceForge, or you could use Apache as a proxy.

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

Yes, but this is the most foolproof system. You manage it like any
other password system. And there's lots of code around for this kind
of thing.

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

Yes, that's always an issue with anything, whether you're using an
extension or not.

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

I'm not sure what you mean by command line. I can launch either a GUI
or non-GUI application from the command line. If it's simply that you
want a simple security solution, there isn't one unless your security
needs are simple. If you want access control lists, you need to build
that, and that will require some infrastructure. None of that infra-
structure would be appropriately *within* Xindice.

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

But you really lose a lot of functionality within Xindice.

>>  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?

As I mentioned above, whether Xindice is launched from the command
line or not, your solution is going to be some combination of modifications
to Xindice (if necessary) and your overall security system (which might
be a part of a proxy, your overall firewall solution, whatever).

>>  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.

Then you need an access control list, either via IP or more probably
via password or encryption with distributed keys. PGP or something
like that would work. You'd put the encrypted data within a CDATA
section within Xindice. But then you really should be looking at
a different type of database, as an XML database whose entire content
is encrypted is kinda pointless. Unless you were willing to write
indexing and querying schemes that decrypted on the fly. That kind of
thing is certainly a possible scheme, but only one of many, and would
be an external module to Xindice, not part of every Xindice distro.
We don't want to bloat Xindice with things that not everyone would
want (esp. since as I've tried to demonstrate, there's many different
ways to solve a specific problem).

>>  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.

Yes, and there's probably others too. Have a big cup of coffee and
put on your thinking cap... you'll come up with something.  :-)

>>I dunno. This is five minutes' effort. I'm sure I could think of
>>more. I'm sure others could too.


Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

  "I'm a war president. I make decisions here in the Oval Office
   in foreign policy matters with war on my mind." -- George W. Bush

  "This is the new Mein Kampf. Only Hitler did not have nuclear
   weapons. It's the scariest document I've ever read in my life."
         -- Dr. Helen Caldicott, referring to the Project for the
   New American Century report entitled "Rebuilding America's
   Defenses: Strategy, Forces and Resources For a New Century"

     "This report proceeds from the belief that America should seek
      to preserve and extend its position of global leadership by
      maintaining the preeminence of U.S. military forces." [op. cit.]

     "[...] and advanced forms of biological warfare that can target
      specific genotypes may transform biological warfare from the
      realm of terror to a politically useful tool." [op. cit.]

  "This is a blueprint for US world domination."

View raw message