xml-xindice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Honglin Ye <...@aoc.nrao.edu>
Subject Re: access control in xindice
Date Wed, 11 Feb 2004 17:26:42 GMT
Murray Altheim wrote:
> 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.
> 
by commandline, I mean things provided by xindice and documented by you (I think it is right
person), something like

xindice xpath -c xmldb:xindice://a.server:7777/db/col_a -q "/root[id='3']"

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


Mime
View raw message