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 Honglin Ye <hy...@aoc.nrao.edu> on 2004/02/10 16:55:00 UTC
access control in xindice
Hi, Vadim,
While I am trying to convince people here we can use
Xindice as our storage component, I found one thing we need
but not yet in xindice.
We need the access control. We can not let people who knows
the host and port to freely query xindice.
I think it should be sufficient to enforce a 'password on collections'.
If a password is set at the collection create time, the access to the collection
and all the child collections later on requires the password. This can be
down on commandline and on programming call.
Do I think about the right thing?
Thanks
Honglin
Re: can xpath to [@key='.....'] ?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Honglin Ye wrote:
> xindice adds src:key=..... attribute to the top level element.
> how to query the doc using this attribute?
If I'm not mistaken, these attributes are added *after* querying, so it
would not be possible to query on those attributes.
Vadim
can xpath to [@key='.....'] ?
Posted by Honglin Ye <hy...@aoc.nrao.edu>.
xindice adds src:key=..... attribute to the top level element.
how to query the doc using this attribute?
Honglin
Re: access control in xindice
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Honglin Ye wrote:
> Vadim Gritsenko wrote:
>
>> More complicated (and better) solution will use username/password
>> provided via Database.getCollection() and give/reject access to the
>> collection based on the authentication (password matches username),
>> and authorization (user is in the group which has access to the
>> collection) rules.
>>
>> Authorization / authentication information should be stored in the db
>> itself, in system collection.
>>
> Hi, Vadim,
> Thanks. Is the solution you provide already in? I need 'the
> better' solution.
No. It needs to be developed.
Vadim
Re: access control in xindice
Posted by Honglin Ye <hy...@aoc.nrao.edu>.
Vadim Gritsenko wrote:
> Honglin Ye wrote:
>
>> Hi, Vadim,
>> While I am trying to convince people here we can use
>> Xindice as our storage component, I found one thing we need
>> but not yet in xindice.
>> We need the access control. We can not let people who knows
>> the host and port to freely query xindice.
>
>
>
> But, generally speaking, it should be behind a firewall.
>
>
>> I think it should be sufficient to enforce a 'password on
>> collections'.
>> If a password is set at the collection create time, the access to the
>> collection
>> and all the child collections later on requires the password. This can be
>> down on commandline and on programming call.
>> Do I think about the right thing?
>
>
>
> Not exactly. The easiest (fastest) way to add simple username/password
> protection is to do so by protecting xindice webapp in web.xml.
>
> More complicated (and better) solution will use username/password
> provided via Database.getCollection() and give/reject access to the
> collection based on the authentication (password matches username), and
> authorization (user is in the group which has access to the collection)
> rules.
>
> Authorization / authentication information should be stored in the db
> itself, in system collection.
>
> Vadim
>
>
>
Hi, Vadim,
Thanks. Is the solution you provide already in? I need 'the better' solution.
I have to hide it from most people within firewall. Where is the instructions
for authentication stuff?
Honglin
Re: access control in xindice
Posted by Vadim Gritsenko <va...@reverycodes.com>.
webhiker@tiscali.fr wrote:
> Would it not be possible just to rely on the Tomcat container
> authorisation mechanism?
I guess so, that's why I wrote:
> The easiest (fastest) way to add simple username/password
> protection is to do so by protecting xindice webapp in web.xml.
In the email you are replying to ;-)
> All that would be needed is a slightly modified datbase driver which
> constructs a proper http/s authentication header.
Yep, that's sounds correct.
> Might require some deviation from the Xml:DB spec.
Not necesserely. XML:DB have a place for driver configuration
parameters, and these are exactly driver configuration parameters.
> Also, won't be applicable for standalone db use.
True.
Vadim
Re: access control in xindice
Posted by "webhiker@tiscali.fr" <we...@tiscali.fr>.
Would it not be possible just to rely on the Tomcat container
authorisation mechanism?
All that would be needed is a slightly modified datbase driver which
constructs a proper http/s authentication header.
Might require some deviation from the Xml:DB spec.
Also, won't be applicable for standalone db use.
wh
JC Tchitchiama wrote:
>Vadim,
>
>One other thing that may be considered is an xml-security layer at the
>document level. A documents can be signed (to prevent fraudulent changes) or
>indeed encrypted to allow only folks with the right public key to access
>(read/edit) the document.
>
>You mentioned username/password at the collection level. I think we should
>have a first authentication at the database instance level and a refined one
>at the collection level. We could also have use roles defined so that one a
>user is logged in depending on one's role one is allowed to perform some
>actions.
>
>I guess these are all ideas for the TODO list ;)
>
>Cheers
>JC
>
>On Tuesday 10 Feb 2004 4:05 pm, Vadim Gritsenko wrote:
>
>
>>Honglin Ye wrote:
>>
>>
>>>Hi, Vadim,
>>> While I am trying to convince people here we can use
>>>Xindice as our storage component, I found one thing we need
>>>but not yet in xindice.
>>> We need the access control. We can not let people who knows
>>>the host and port to freely query xindice.
>>>
>>>
>>But, generally speaking, it should be behind a firewall.
>>
>>
>>
>>> I think it should be sufficient to enforce a 'password on
>>>collections'.
>>>If a password is set at the collection create time, the access to the
>>>collection
>>>and all the child collections later on requires the password. This can be
>>>down on commandline and on programming call.
>>> Do I think about the right thing?
>>>
>>>
>>Not exactly. The easiest (fastest) way to add simple username/password
>>protection is to do so by protecting xindice webapp in web.xml.
>>
>>More complicated (and better) solution will use username/password
>>provided via Database.getCollection() and give/reject access to the
>>collection based on the authentication (password matches username), and
>>authorization (user is in the group which has access to the collection)
>>rules.
>>
>>Authorization / authentication information should be stored in the db
>>itself, in system collection.
>>
>>Vadim
>>
>>
>
>
>
>
Re: access control in xindice
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Vadim Gritsenko wrote:
>> I think we should have a first authentication at the database
>> instance level and a refined one at the collection level. We could
>> also have use roles defined so that one a user is logged in depending
>> on one's role one is allowed to perform some actions.
>
Those interested in auth, see Wiki page:
http://wiki.apache.org/xindice/BasicAuthentication
Vadim
PHP interface to Xindice
Posted by Jim Fuller <ji...@ruminate.co.uk>.
XINDICE PHP ADMIN
I have created an xindice php administrative interface which was
developed using Jill Rhoads existing Xindice.php xindice class as the
main interface.
This prototype is intended for instructing PHP developers on how to
easily place a
facade onto Xindice. It is by no means complete though is quite usable.
You can download Xindice PHP Admin from
http://www.ruminate.co.uk/samples/xindice_php_admin_v.0.Alpha.zip
Cheers, Jim Fuller
Re: access control in xindice
Posted by Stefan Lischke <li...@novacom.net>.
Hi,
I have another nice Method for secure acces to xindice which i used a year
ago, so i dont know if its possible with the actual version.
First u have to change your config.xml and tell xindice, that it only
accept connections made from localhost.
Now u set up a ssh tunnel from the machine where u want to acces xindice
(for example with xmldbgui) to the xindice server machine and port.
Login is now made via ssh to the server machine which should be secure.
Now your are talking to xindice with localhost:1111 which is mapped via
ssh tunnel to xindice-server:7777
hope this helps.
stefan
Re: access control in xindice
Posted by Honglin Ye <hy...@aoc.nrao.edu>.
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
>
Re: access control in xindice
Posted by Murray Altheim <m....@open.ac.uk>.
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
......................................................................
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
http://news.bbc.co.uk/1/hi/world/americas/3470139.stm
"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"
http://home.earthlink.net/~platter/neo-conservatism/pnac.html
"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."
http://www.guardian.co.uk/comment/story/0,3604,1036571,00.html
Re: access control in xindice
Posted by Honglin Ye <hy...@aoc.nrao.edu>.
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
>
Re: access control in xindice
Posted by Murray Altheim <m....@open.ac.uk>.
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?
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).
2. create an IP access control list to filter access via incoming
IP addresses
3. use a user-based system:
a. via username-password
b. via domain-based filtering
4. extend one or two of Xindice's classes to enable data flow based on
any number of factors.
5. use a cookie-based system (i.e., if the user query doesn't have
the right cookie, deny service
6. encrypt all data stored in Xindice (prior to going into Xindice)
and give the keys only to trusted clients
7. extend the client to require a preliminary handshaking, where
the server challenges the client to produce a hash.
8. make the port available only within your LAN/WAN
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.
I dunno. This is five minutes' effort. I'm sure I could think of
more. I'm sure others could too.
Murray
......................................................................
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
http://news.bbc.co.uk/1/hi/world/americas/3470139.stm
"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"
http://home.earthlink.net/~platter/neo-conservatism/pnac.html
"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."
http://www.guardian.co.uk/comment/story/0,3604,1036571,00.html
Re: access control in xindice
Posted by Honglin Ye <hy...@aoc.nrao.edu>.
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?
Thanks
Re: access control in xindice
Posted by Murray Altheim <m....@open.ac.uk>.
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
......................................................................
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
http://news.bbc.co.uk/1/hi/world/americas/3470139.stm
"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"
http://home.earthlink.net/~platter/neo-conservatism/pnac.html
"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."
http://www.guardian.co.uk/comment/story/0,3604,1036571,00.html
Re: access control in xindice
Posted by Honglin Ye <hy...@aoc.nrao.edu>.
Murray Altheim wrote:
> Vadim Gritsenko wrote:
>
>> JC Tchitchiama wrote:
>
> [...]
>
>>> One other thing that may be considered is an xml-security layer at
>>> the document level. A documents can be signed (to prevent fraudulent
>>> changes) or indeed encrypted to allow only folks with the right
>>> public key to access (read/edit) the document.
>>
>>
>> I think xml-security is outside of the scope of Xindice: you can
>> implement xml-security on top of Xindice, in your application.
>> Another option might be a driver which wraps another driver and
>> provides xml-security encryption / decryption transparantly.
>
>
> I agree. I'd much rather have any development time spent on getting
> 1.1 completely up and running, fixing bugs, improving performance
> and existing features like indexing, before anybody starts heading
> down paths that are complete projects in their own right. Vadim has
> been putting enormous energy into just keeping Xindice from dying as
> a project. The idea of branching off on only orthogonally-related
> things like security prior to even a 2.0 release seems very premature.
> Stability and performance are a lot more important.
>
> Murray
>
> ......................................................................
> 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
> http://news.bbc.co.uk/1/hi/world/americas/3470139.stm
>
> "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"
> http://home.earthlink.net/~platter/neo-conservatism/pnac.html
>
> "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."
> http://www.guardian.co.uk/comment/story/0,3604,1036571,00.html
>
>
>
>
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)
Honglin
Re: access control in xindice
Posted by Murray Altheim <m....@open.ac.uk>.
Vadim Gritsenko wrote:
> JC Tchitchiama wrote:
[...]
>>One other thing that may be considered is an xml-security layer at the
>>document level. A documents can be signed (to prevent fraudulent changes) or
>>indeed encrypted to allow only folks with the right public key to access
>>(read/edit) the document.
>
> I think xml-security is outside of the scope of Xindice: you can
> implement xml-security on top of Xindice, in your application.
> Another option might be a driver which wraps another driver and provides
> xml-security encryption / decryption transparantly.
I agree. I'd much rather have any development time spent on getting
1.1 completely up and running, fixing bugs, improving performance
and existing features like indexing, before anybody starts heading
down paths that are complete projects in their own right. Vadim has
been putting enormous energy into just keeping Xindice from dying as
a project. The idea of branching off on only orthogonally-related
things like security prior to even a 2.0 release seems very premature.
Stability and performance are a lot more important.
Murray
......................................................................
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
http://news.bbc.co.uk/1/hi/world/americas/3470139.stm
"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"
http://home.earthlink.net/~platter/neo-conservatism/pnac.html
"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."
http://www.guardian.co.uk/comment/story/0,3604,1036571,00.html
Re: access control in xindice
Posted by Vadim Gritsenko <va...@reverycodes.com>.
JC Tchitchiama wrote:
>Vadim,
>
>One other thing that may be considered is an xml-security layer at the
>document level. A documents can be signed (to prevent fraudulent changes) or
>indeed encrypted to allow only folks with the right public key to access
>(read/edit) the document.
>
>
I think xml-security is outside of the scope of Xindice: you can
implement xml-security on top of Xindice, in your application.
Another option might be a driver which wraps another driver and provides
xml-security encryption / decryption transparantly.
>You mentioned username/password at the collection level.
>
Because that's part of XML:DB spec:
/**
* Retrieves a <code>Collection</code> instance based on the URI
provided
* in the <code>uri</code> parameter. The format of the URI is
defined in the
* documentation for DatabaseManager.getCollection().<p/>
*
* Authentication is handled via username and password however it is not
* required that the database support authentication. Databases that
do not
* support authentication MUST ignore the
* <code>username</code> and <code>password</code> if those provided
are not
* null.
*
* @param uri the URI to use to locate the collection.
* @param password The password to use for authentication to the
database or
* null if the database does not support authentication.
* @return A <code>Collection</code> instance for the requested
collection or
* null if the collection could not be found.
* @return The <code>Collection</code> instance
* @exception XMLDBException with expected error codes.<br />
* <code>ErrorCodes.VENDOR_ERROR</code> for any vendor
* specific errors that occur.<br />
* <code>ErrroCodes.INVALID_URI</code> If the URI is not in a valid
format. <br />
* <code>ErrroCodes.PERMISSION_DENIED</code> If the
<code>username</code>
* and <code>password</code> were not accepted by the database.
*/
Collection getCollection(String uri, String username, String password)
throws XMLDBException;
>I think we should
>have a first authentication at the database instance level and a refined one
>at the collection level. We could also have use roles defined so that one a
>user is logged in depending on one's role one is allowed to perform some
>actions.
>
>
I agree on roles stuff.
Vadim
Re: access control in xindice
Posted by Stefan Lischke <li...@novacom.net>.
Hi all,
On Wed, 11 Feb 2004, JC Tchitchiama wrote:
> You mentioned username/password at the collection level. I think we should
> have a first authentication at the database instance level and a refined one
> at the collection level. We could also have use roles defined so that one a
> user is logged in depending on one's role one is allowed to perform some
> actions.
>
> I guess these are all ideas for the TODO list ;)
Why invent the wheel new? Did u ever take a look at security and
usermanagement in eXist? It has a user and group management, owner group
and other permission (read write update).
These users are also used for database instance authentication. There is
also a java gui for usermanagement.
So take a look at it, take the best from it and do it better.
stefan
Re: access control in xindice
Posted by JC Tchitchiama <jc...@panonet.net>.
Vadim,
One other thing that may be considered is an xml-security layer at the
document level. A documents can be signed (to prevent fraudulent changes) or
indeed encrypted to allow only folks with the right public key to access
(read/edit) the document.
You mentioned username/password at the collection level. I think we should
have a first authentication at the database instance level and a refined one
at the collection level. We could also have use roles defined so that one a
user is logged in depending on one's role one is allowed to perform some
actions.
I guess these are all ideas for the TODO list ;)
Cheers
JC
On Tuesday 10 Feb 2004 4:05 pm, Vadim Gritsenko wrote:
> Honglin Ye wrote:
> > Hi, Vadim,
> > While I am trying to convince people here we can use
> > Xindice as our storage component, I found one thing we need
> > but not yet in xindice.
> > We need the access control. We can not let people who knows
> > the host and port to freely query xindice.
>
> But, generally speaking, it should be behind a firewall.
>
> > I think it should be sufficient to enforce a 'password on
> > collections'.
> > If a password is set at the collection create time, the access to the
> > collection
> > and all the child collections later on requires the password. This can be
> > down on commandline and on programming call.
> > Do I think about the right thing?
>
> Not exactly. The easiest (fastest) way to add simple username/password
> protection is to do so by protecting xindice webapp in web.xml.
>
> More complicated (and better) solution will use username/password
> provided via Database.getCollection() and give/reject access to the
> collection based on the authentication (password matches username), and
> authorization (user is in the group which has access to the collection)
> rules.
>
> Authorization / authentication information should be stored in the db
> itself, in system collection.
>
> Vadim
Re: access control in xindice
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Honglin Ye wrote:
> Hi, Vadim,
> While I am trying to convince people here we can use
> Xindice as our storage component, I found one thing we need
> but not yet in xindice.
> We need the access control. We can not let people who knows
> the host and port to freely query xindice.
But, generally speaking, it should be behind a firewall.
> I think it should be sufficient to enforce a 'password on
> collections'.
> If a password is set at the collection create time, the access to the
> collection
> and all the child collections later on requires the password. This can be
> down on commandline and on programming call.
> Do I think about the right thing?
Not exactly. The easiest (fastest) way to add simple username/password
protection is to do so by protecting xindice webapp in web.xml.
More complicated (and better) solution will use username/password
provided via Database.getCollection() and give/reject access to the
collection based on the authentication (password matches username), and
authorization (user is in the group which has access to the collection)
rules.
Authorization / authentication information should be stored in the db
itself, in system collection.
Vadim