xml-xindice-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From JC Tchitchiama <...@panonet.net>
Subject Re: access control in xindice
Date Wed, 11 Feb 2004 12:15:39 GMT
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


Mime
View raw message