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
