Re: [Exist-open] User authentification and access control

[Graham S. <gr...@se...>]

[off-topic: I didn't reply to Wolfgang's original message because it
was unreadable in pine, my mail reader - just displayed ' [Error: 
Formatting error: Non-hexadecimal character in QP encoding]'. I believe
this is due to the mail sender declaring the type as 'Quoted-Printable'
in spite of the fact that the mail contains non-uriescaped characters
somewhere... does anyone know a solution to this?  I get this in quite
a few mails to this list, though not generally on other lists]


On Thu, 22 Aug 2002, Bill Eldridge wrote:

> Wolfgang Meier wrote:
> > I'm currently working to add user authentification and access control rights 
> > to eXist (I need this for another project). So far I have implemented users, 
> > groups and Unix-like access rights for documents and collections.  I have 
> > also extended the embedded XML:DB driver to handle user authentification.
> 
> I think Unix-like access will be a bit painful for a database,
> though you may have made this a bit more obvious in your version.
> Add, Delete, View, Modify, Backup, ... as well as a different
> rights sets for different groups on the same document/collection,
> better inheritance schemes, etc.  I'm not sure who offers a good
> model for this.

It seems a little over the top to me. I can see it for collections
(by analogy with SQL tables) more than for individual documents. But
judging by my experience with unix file permissions, if you do it this
way I hope there are some simple commands to change ownerships ;-) 

> 
> > Now I'm thinking about how to implement authentification in the XML-RPC 
> > interface. The Apache XMLRPC library offers an authenticated handler, but I'm 
> > not sure if e.g. Perl or Python libraries support this. 
> 
> If the authentication portion isn't that tough,
> it might be easy enough to subclass Python's xmlrpc
> module and add the authentication ourselves.
> I already wrote my own Python XMLRPC API interface
> to eXist, so a few more hacks might not be a big deal.

I believe the Apache XML-RPC is just basic auth? (ie. no ssl or other
real encryption)? If so, then it shouldn't be hard to manage for either
the XMLRPC::Lite or RPC::XML modules, both of which use LWP::UserAgent
for transport - and LWP::UserAgent provides Basic Auth. It might mean
that RPC::XML no longer works 'out of the box', but needs a manual tweak - 
I'm not sure, not having ever tried this out. But then I already have to
tweak RPC::XML by extending the LWP::UserAgent timeout constant to allow
for long queries... 
> 
> 
> > Another possiblity would be to extend every method to expect username and 
> > password (MD5 digest) as additional arguments, but this would result in long 
> > parameter lists. As a third alternative, we could introduce a login-method 
> > which returns a session-id (which should be used in subsequent method calls).
> 
> Well, I think session-id's will be necessary anyway
> (and close to the idea of resultId's already implemented?).

How would this work if exist was running as backend to a web site? 
Would the web server keep having to login every session-expiry-time?
Or for each individual web-server thread? 
> 
> So I'd vote for options 1 & 3.  There's also SSL Cocoon access,
> which I tried getting working a year ago with only a slight
> bit of success. (I posted my dismal failure results I believe).
>
After a quick bit of googling, there seems to have been a lot of 
discussion about including SSL in the XML-RPC spec. But most of it
seems inconclusive - is there a single forum which has 'authoritative'
discussions on XML-RPC? If so, it might be worth finding out what the
general consensus is on security for XML-RPC, rather than creating
a one-off method, so general support is more likely for the future.

Cheers
graham 

 
>