Hi,
one of the features I am missing in Xindice is the lack of security. I
found some notes towards this subject in the plannings and I also have some
thoughts to share.
>Access control
Back in the nineties I was working for an American company which sold
solutions based on an improved X.500 directory. The security concept there
was based on ACIs (Access Control Items) which could be placed anywhere in
the directory tree, applying to the immediate subtree. The security context
for a node resulted in the cascade of ACIs on the path to that node. The
last ACI would always overpower the preceding in case of a rights conflict.
>Could be collection, document or node level.
What about defining a kind of security tree inside of Xindice? This
security tree would define ACNs (Access Nontrol Nodes) wherever necessary.
The default definition would only have a single ACN granting rights for the
Xindice administrator (Authorization has to fit tightly into this concept,
of course). If you want to specify access control to a document you would
have to define an ACN in the security tree which is late checked by the
XPath engine by simply applying the full path to the resulting entry on the
security tree and overlaying all found ACNs.
Example:
An XPath query by User1 would result in returning the following entry from a
collection named "foo": /rootElement/nodeElement/l2NodeElement
The security tree has three ACNs:
1. Xindice: grant all to Administrator
2. Xindice/db/collections/foo: grant read to User1
3. Xindice/db/collections/foo/rootElement/nodeElement: deny read for User1
Applying the result to the security tree results in the following
Authorization:
grant all to Administrator and deny read for User1
The ACN in "nodeElement" has the highest priority and negates the grant on
collection level.
--> the result would not be returned to User1
The same document in a different collection could be secured completely
different.
This is only a very simple example but it should make clear the idea:
"Put in a maximum of flexible security with a minimum of data".
The system I described would allow any level of granularity the user could
think of.
>Authorization
Authorization should follow the same pattern as it does in all the other
APIs for accessing services: By being bound to the connection. Simply
specify security credentials and then let the connection decide if you will
be connected. The security context would then be sent to the DB in all
further interactions. Simple and commonly used.
Okay and we would definitely need a user DB, and flexible right groups.
Maybe we could reuse some concepts from JAAS?
>Encryption?
>With HTTP based protocols and integrated SSL network level encryption
should be relatively simple. Depends on where we go for server framework
Yes, that sounds good. Do not reinvent what others have long done better.
So what do you think about putting some security into Xindice? If you can
bear with my slow performance on this subject (Hey, I have a family and a
job and some other hobbies) I'd like to try some things or help anybody who
is already involved.
Tchaw!
Christoph
__________________/\/\/\/\__________________
[EMAIL PROTECTED]
http://www.christoph-krueger.de
ICQ: #63047424
