On Friday, March 15, 2002, at 08:05 PM, Mike Gratton wrote:
I'm wondering if it is really worthwhile putting something quick and dirty in untill a better solution is developed. It'd probably be easy to hack something together right now using http auth and clear text in files,
but someone will most likely get burnt from such an implementation. Their clear text password file will get read, their non-https connection will get intercepted.
Well that was my original thinking too, and is the reason Xindice does not have security today. I started to implement security, but realized I really didn't have time to do it right, or even know how to do it right given how new the native XML database idea is. I've changed my mind now and think a system that is obviously simplistic will be sufficient for the short term. I don't think it is a good solution, but my concern is with the lack of granular multiuser features more then it is with the basic auth mechanism. The solutions to basic auth flaws are well known. For instance SSL can easily be added via a tunnel if you really need to access Xindice over an insecure network.
BTW, I don't know if the password as stored is clear text or not. I doubt it is, but even if it is that's trivial to change.
The question I'm asking is, do people consider it important enough to get user authentication in 1.1, even if it means having such an easily defeated model?
I didn't, but I do now, mainly because most connections to Xindice will not be over a public network. Over time that may change, but over time we'
ll also build a better system.
The major problem right now is that if you only have one machine then Xindice is going to run publicly accessible even if all your connections are local. Ideally you have port filtering in place, but who knows. This is a huge barrier for real use as most people only have one machine and may not have any control over port policies.
Personally, I'd much prefer to have ACL-style connection security before seeing an authentication mechanism in 1.1. To be able to say, "listen on this interface, on this port, but only accept connections from this IP address." (Someone should feel free to correct me if Xindice can already do this, but I've never seen it in the docs..).
No it can't, at least not easily.
In any case, one possibility for Xindice's "proper" user authentication mechanism is JAAS <http://java.sun.com/products/jaas/>. For those who aren't familiar with JAAS, it's a modular user authentication and access control framework (similar or PAM), which lets you use pluggable authentication backends. It's standard in 1.4, optional in 1.3. I've been wanting to have a play with JAAS for a while now, so perhaps integrating into Xindice would be that oppurtunity.
I don't know if that's what we need or not, but it's certainly worth exploring. A lot of people have expressed interest in working on security.
Thus far no one has stepped up to take ownership of it. Chad La Joie was starting to, but I haven't heard anything from him lately.
Mike.
-- Mike Gratton <[EMAIL PROTECTED]>, <http://web.vee.net/> "Every motive escalate."
Kimbro Staken - http://www.kstaken.org - http://www.xmldatabases.org Apache Xindice native XML database http://xml.apache.org/xindice XML:DB Initiative http://www.xmldb.org Senior Technologist (Your company name here)
