You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Chad La Joie <cl...@vt.edu> on 2002/01/14 23:31:49 UTC
Possible Features
Well here are the lists of things I'd kind of like to see from Xindice
1. Lose CORBA, or at least give an alternative. I haven't taken an in
depth look at the code yet, but it seems that the CORBA interface to the
system is tightly coupled with the actual server. It seems to me that
breaking this coupling would make it easier to create some other
interfaces, like a SOAP interface.
2. Consider using the W3C XQuery recommendation in addition to the XPath
support you already have.
3. Consider allowing a XML Schema or DTD to loaded into DB so that system
could automatically type check entries. You could also might be able to
use this to help with optimizing indexing (not sure how, it's just a thought).
4. Consider some sort of authorization system. For instance, jsmith can
view these collections of these databases, but nothing else.
I'd be happy to help with 1 and 4.
Chad La Joie "It is true that you never know what
Middleware Services you have until it is gone, but it is also
IS&C - Virginia Tech true that you never know what you've
been missing until it arrives."
Re: Possible Features
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
On Tuesday, January 15, 2002, at 05:36 PM, Chad La Joie wrote:
> I agree, such functionality would be nice. I thought I might start
> taking a look into what was started with security so far and maybe do
> some work on it. Is there anyone actively working on/in charge of this
> section? Here are my thoughts so far on the security.
>
I wrote the code about nine months ago and haven't touched it since we
decided to leave it out of 1.0. You're more then welcome to pick it up and
run with it.
> 1. Support of user authentication entities (i.e. userid/passwd to
> connect)
> 2. Support user/group authorization entities (i.e. these users, or
> members of these groups, can connect, read, write, etc)
> 3. Support multiple back stores for this data (the current work uses an
> XML file, it would be nice to have LDAP and Database support as well)
If i remember right the current code is interface based for this very
reason. I wouldn't worry about writing any of these things to start though.
> 4. Support restrictions on the following:
> - create, query, update, remove, create XMLObject, remove XMLObjects,
> create Indexes, remove Indexes for collection
> - Connect, create collection, remove collection for databases.
>
I just dug out my notes, I also had execute for XMLObjects.
Some other things that need to be considered.
- APIs for ACL config and user config
- Command line tools for the same
- Authentication APIs for access services. For instance it needs to be
easy to add another network interface and tie it into the auth system.
- Logging / Auditing
- How to configure the initial server setup
- How the server can bootstrap itself to get through the security controls.
> At 01:50 PM 1/15/2002, you wrote:
>> I see in the source code that you are working on user/group security and
>> read and write access. One powerful feature would be to add xpath based
>> security. By allowing a user or group read/write access to a specific
>> xpath in a collection or document.
>>
>> <person>
>> <name>John Doe</name>
>> <salary>1000</salary> <- no access
>> </person>
>>
>> ---- not real - access xml doc ---
>> <group>
>> <user id="bigboss">
>> <access>
>> <collection id="documents">
>> <xpath>//salary</xpath>
>> <privileges>none</privileges>
>> </collection>
>> </access>
>> </user>
>> </group>
>>
>> This is just a quick example - an a final suggestion.
>>
>> What do you think?
>>
>> Regards, Niels Peter
>
>
>
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/
Re: Possible Features
Posted by Chad La Joie <cl...@vt.edu>.
I agree, such functionality would be nice. I thought I might start taking
a look into what was started with security so far and maybe do some work on
it. Is there anyone actively working on/in charge of this section? Here
are my thoughts so far on the security.
1. Support of user authentication entities (i.e. userid/passwd to connect)
2. Support user/group authorization entities (i.e. these users, or members
of these groups, can connect, read, write, etc)
3. Support multiple back stores for this data (the current work uses an
XML file, it would be nice to have LDAP and Database support as well)
4. Support restrictions on the following:
- create, query, update, remove, create XMLObject, remove XMLObjects,
create Indexes, remove Indexes for collection
- Connect, create collection, remove collection for databases.
At 01:50 PM 1/15/2002, you wrote:
>I see in the source code that you are working on user/group security and
>read and write access. One powerful feature would be to add xpath based
>security. By allowing a user or group read/write access to a specific
>xpath in a collection or document.
>
><person>
> <name>John Doe</name>
> <salary>1000</salary> <- no access
></person>
>
>---- not real - access xml doc ---
><group>
> <user id="bigboss">
> <access>
> <collection id="documents">
> <xpath>//salary</xpath>
> <privileges>none</privileges>
> </collection>
> </access>
> </user>
></group>
>
>This is just a quick example - an a final suggestion.
>
>What do you think?
>
>Regards, Niels Peter
Re: Possible Features
Posted by Lars Martin <La...@smb-tec.com>.
On Wed, 16 Jan 2002 03:52:58 -0700
Kimbro Staken <ks...@dbxmlgroup.com> wrote:
>
> On Tuesday, January 15, 2002, at 11:50 AM, Niels Peter Strandberg wrote:
>
> > I see in the source code that you are working on user/group security and
> > read and write access. One powerful feature would be to add xpath based
> > security. By allowing a user or group read/write access to a specific
> > xpath in a collection or document.
> >
> > <person>
> > <name>John Doe</name>
> > <salary>1000</salary> <- no access
> > </person>
> >
> > ---- not real - access xml doc ---
> > <group>
> > <user id="bigboss">
> > <access>
> > <collection id="documents">
> > <xpath>//salary</xpath>
> > <privileges>none</privileges>
> > </collection>
> > </access>
> > </user>
> > </group>
> >
> > This is just a quick example - an a final suggestion.
> >
>
> This is the kind of thing several people have asked for.
>
> I'm just going to throw out some random thoughts, thinking out loud.
>
> You'd have to check all XPaths defined for a collection each time a
> document is retrieved or updated or a query is executed. If you do this at
> a sufficiently low level it shouldn't be too difficult, but it will have a
> real impact on how things like query results are handled. For instance it
> would be very possible to have a query where some results are allowed and
> some aren't.
>
> It also impacts how documents are returned. What happens if you're
> restricted from just part of a document? Do you not get the document at
> all or do you just get the part you're allowed access to?
>
> If you do only return part of the document, what happens when the person
> modifies it and tries to store it back?
>
> If you do just deny the whole document then why even bother with the path
> based access control? Actually, it'd probably still be useful for denying
> the same document to different users for different reasons. Hmm, that
> might work, but you'd also be denying access to information that a user
> should have access to if they're only denied for part of a document.
>
> This also applies to queries. What happens when a query is allowed to
> access part of document, but is denied from the rest?
>
> To make it efficient you'd probably have to have some kind of permissions
> cache that is maintained every time a document is modified.
>
> Reconciling multiple paths will be tricky, especially if you allow things
> like the descendent-or-self axis. It might be worth considering only
> allowing a subset of XPath axis.
>
> Namespaces must be considered, which means you need to be able to define a
> ns prefix before using it in a path.
>
> Just some quick thoughts.
>
> > What do you think?
What about XML Access Control to be found at
http://www.xmldb.org/projects.html and proposed by Jonathan Borden?
--
______________________________________________________________________
Lars Martin mailto:Lars.Martin@smb-tec.com
SMB GmbH http://www.smb-tec.com
Re: Possible Features
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
On Tuesday, January 15, 2002, at 11:50 AM, Niels Peter Strandberg wrote:
> I see in the source code that you are working on user/group security and
> read and write access. One powerful feature would be to add xpath based
> security. By allowing a user or group read/write access to a specific
> xpath in a collection or document.
>
> <person>
> <name>John Doe</name>
> <salary>1000</salary> <- no access
> </person>
>
> ---- not real - access xml doc ---
> <group>
> <user id="bigboss">
> <access>
> <collection id="documents">
> <xpath>//salary</xpath>
> <privileges>none</privileges>
> </collection>
> </access>
> </user>
> </group>
>
> This is just a quick example - an a final suggestion.
>
This is the kind of thing several people have asked for.
I'm just going to throw out some random thoughts, thinking out loud.
You'd have to check all XPaths defined for a collection each time a
document is retrieved or updated or a query is executed. If you do this at
a sufficiently low level it shouldn't be too difficult, but it will have a
real impact on how things like query results are handled. For instance it
would be very possible to have a query where some results are allowed and
some aren't.
It also impacts how documents are returned. What happens if you're
restricted from just part of a document? Do you not get the document at
all or do you just get the part you're allowed access to?
If you do only return part of the document, what happens when the person
modifies it and tries to store it back?
If you do just deny the whole document then why even bother with the path
based access control? Actually, it'd probably still be useful for denying
the same document to different users for different reasons. Hmm, that
might work, but you'd also be denying access to information that a user
should have access to if they're only denied for part of a document.
This also applies to queries. What happens when a query is allowed to
access part of document, but is denied from the rest?
To make it efficient you'd probably have to have some kind of permissions
cache that is maintained every time a document is modified.
Reconciling multiple paths will be tricky, especially if you allow things
like the descendent-or-self axis. It might be worth considering only
allowing a subset of XPath axis.
Namespaces must be considered, which means you need to be able to define a
ns prefix before using it in a path.
Just some quick thoughts.
> What do you think?
>
> Regards, Niels Peter
>
>
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/
Re: Possible Features
Posted by Niels Peter Strandberg <ni...@npstrandberg.com>.
Oops! Should have been "NOT" a final suggestion.
> This is just a quick example - an a final suggestion.
Re: Possible Features
Posted by Niels Peter Strandberg <ni...@npstrandberg.com>.
I see in the source code that you are working on user/group security and
read and write access. One powerful feature would be to add xpath based
security. By allowing a user or group read/write access to a specific
xpath in a collection or document.
<person>
<name>John Doe</name>
<salary>1000</salary> <- no access
</person>
---- not real - access xml doc ---
<group>
<user id="bigboss">
<access>
<collection id="documents">
<xpath>//salary</xpath>
<privileges>none</privileges>
</collection>
</access>
</user>
</group>
This is just a quick example - an a final suggestion.
What do you think?
Regards, Niels Peter
On tisdag, januari 15, 2002, at 03:58 , Kimbro Staken wrote:
>
> On Monday, January 14, 2002, at 03:31 PM, Chad La Joie wrote:
>
>> Well here are the lists of things I'd kind of like to see from Xindice
>>
>> 1. Lose CORBA, or at least give an alternative. I haven't taken an
>> in depth look at the code yet, but it seems that the CORBA interface
>> to the system is tightly coupled with the actual server. It seems to
>> me that breaking this coupling would make it easier to create some
>> other interfaces, like a SOAP interface.
>>
>
> XML-RPC is already available as an alternative. In reality there is no
> tight coupling between the server and CORBA. It's very easy to add
> whatever other protocol that you want. Where there is a tight coupling
> right now is between the XML:DB API implementation and CORBA. That
> doesn't prevent other protocols from being added, it just makes it
> difficult to completely get rid of CORBA. Getting rid of CORBA is
> something we've wanted to do for a while.
>
>> 2. Consider using the W3C XQuery recommendation in addition to the
>> XPath support you already have.
>>
>
> Just to be picky I have to say, what XQuery recommendation? :-) XQuery
> is still very much a working draft and will be for a while. We're of
> course planning to support it and there has been a bit more discussion
> about really getting going on it lately. We really need someone to step
> up and take ownership for the project.
>
>> 3. Consider allowing a XML Schema or DTD to loaded into DB so that
>> system could automatically type check entries. You could also might
>> be able to use this to help with optimizing indexing (not sure how,
>> it's just a thought).
>>
>
> There's been a lot of discussion lately about this too. We've always
> planned to add XML Schema support eventually. Right now most of the
> discussion has been around what Schema languages to support and at what
> level in the server. Again we really need someone to take ownership of
> this to really get it moving.
>
>> 4. Consider some sort of authorization system. For instance, jsmith
>> can view these collections of these databases, but nothing else.
>>
>
> The same thing applies here, been planned for a while and in this case
> there is even some code around but it isn't finished.
>
>> I'd be happy to help with 1 and 4.
>
> Great, for 1 take a look at these projects.
>
> http://www.xmldatabases.org/projects/dbXML-XMLRPC/
> http://sourceforge.net/projects/xindice-xmlrpc/ - This will replace
> dbXML-XMLRPC and update it for Xindice
> http://notdotnet.org/
>
> All of these are outside the core Xindice project, but I expect the
> work to be rolled back in eventually. We wanted to experiment a bit.
>
> For 4 take a look at the source in org.apache.xindice.core.security. We
> don't need to keep any of that code, but it's worth looking at as a
> starting point. One of the main reasons I never finished the initial
> security system is that I wanted to make sure security was carefully
> considered. Now that there are more eyes looking at the code it's a
> good time to start to dig into the security framework. Yet again, we
> need someone to take ownership of it.
>
>>
>> Chad La Joie "It is true that you never know
>> what
>> Middleware Services you have until it is gone, but it
>> is also
>> IS&C - Virginia Tech true that you never know what
>> you've
>> been missing until it
>> arrives."
>>
>>
>>
> Kimbro Staken
> XML Database Software, Consulting and Writing
> http://www.xmldatabases.org/
>
Re: Possible Features
Posted by Kimbro Staken <ks...@dbxmlgroup.com>.
On Monday, January 14, 2002, at 03:31 PM, Chad La Joie wrote:
> Well here are the lists of things I'd kind of like to see from Xindice
>
> 1. Lose CORBA, or at least give an alternative. I haven't taken an in
> depth look at the code yet, but it seems that the CORBA interface to the
> system is tightly coupled with the actual server. It seems to me that
> breaking this coupling would make it easier to create some other
> interfaces, like a SOAP interface.
>
XML-RPC is already available as an alternative. In reality there is no
tight coupling between the server and CORBA. It's very easy to add
whatever other protocol that you want. Where there is a tight coupling
right now is between the XML:DB API implementation and CORBA. That doesn't
prevent other protocols from being added, it just makes it difficult to
completely get rid of CORBA. Getting rid of CORBA is something we've
wanted to do for a while.
> 2. Consider using the W3C XQuery recommendation in addition to the XPath
> support you already have.
>
Just to be picky I have to say, what XQuery recommendation? :-) XQuery is
still very much a working draft and will be for a while. We're of course
planning to support it and there has been a bit more discussion about
really getting going on it lately. We really need someone to step up and
take ownership for the project.
> 3. Consider allowing a XML Schema or DTD to loaded into DB so that
> system could automatically type check entries. You could also might be
> able to use this to help with optimizing indexing (not sure how, it's
> just a thought).
>
There's been a lot of discussion lately about this too. We've always
planned to add XML Schema support eventually. Right now most of the
discussion has been around what Schema languages to support and at what
level in the server. Again we really need someone to take ownership of
this to really get it moving.
> 4. Consider some sort of authorization system. For instance, jsmith can
> view these collections of these databases, but nothing else.
>
The same thing applies here, been planned for a while and in this case
there is even some code around but it isn't finished.
> I'd be happy to help with 1 and 4.
Great, for 1 take a look at these projects.
http://www.xmldatabases.org/projects/dbXML-XMLRPC/
http://sourceforge.net/projects/xindice-xmlrpc/ - This will replace
dbXML-XMLRPC and update it for Xindice
http://notdotnet.org/
All of these are outside the core Xindice project, but I expect the work
to be rolled back in eventually. We wanted to experiment a bit.
For 4 take a look at the source in org.apache.xindice.core.security. We
don't need to keep any of that code, but it's worth looking at as a
starting point. One of the main reasons I never finished the initial
security system is that I wanted to make sure security was carefully
considered. Now that there are more eyes looking at the code it's a good
time to start to dig into the security framework. Yet again, we need
someone to take ownership of it.
>
> Chad La Joie "It is true that you never know
> what
> Middleware Services you have until it is gone, but it is
> also
> IS&C - Virginia Tech true that you never know what you've
> been missing until it
> arrives."
>
>
>
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/