[protege-discussion] WebProtege and user accounts

[Thomas Russ]

First off, let me say that I don't have any particular insight to  
WebProtege.  These comments are just general, client-server issues.

On Oct 2, 2009, at 9:57 AM, Shahim Essaid wrote:

> Hello,
>
> I am trying WebProtege build 200 for the first time.  I noticed few  
> issues with how WebProtege handles the user accounts unless I have  
> something wrong on my end.  Below are some observations but I am not  
> sure if this is a problem on my side or if it is the limitation of  
> alpha software.
>
> 	• WebProtege needs read access in addition to list access before it  
> can show the project names.  This is different from the Protege  
> client setup.
> 	• WebProtege does not take-on the identity of the logged in user.   
> All edits show as being performed by WebProtege.  This doesn't help  
> with change tracking.
> 	• The WebProtege user account needs to have write access since it  
> doesn't use the rights of the logged in user.  This is not helpful  
> because access rights can not be well controlled.
> 	• WebProtege uses the rights of the logged in user to activate few  
> additional buttons but the actual read and write actions are done by  
> using the WebProtege user account.  One interesting side effect of  
> this was the following: I logged in with my account and WebProtege  
> activated the add/delete class buttons.  I then logged out but the  
> buttons remained active and I could still add/delete classes even  
> after I logged out because WebProtege has write access.  The buttons  
> were deactivated if I refresh the page but simply logging out does  
> not do that.
> 	• If I don't give WebProtege write access then no user can edit the  
> ontology because WebProtege doesn't take on their identity and use  
> their privileges.
> Is this how WebProtege build 200 is supposed to behave?

The real problem is that when you run any server program, it has to be  
run (at least in Unix-style systems) as some user.  In the case of  
WebProtege, it seems that it runs as the webprotege user.  But when  
running as the webprotege user, it will typically not be able to  
change it's user id.  It presumably also runs its own separate set of  
users and logins, so that you can give users access to the WebProtege  
service without having to create accounts for them on your machine.

This is generally a good thing, since it limits the damage that can be  
done if the system is successfully attacked.  If WebProtege were able  
to take on any user identity, then a breech in its security would  
imperil the entire machine, since the intruder could impersonate  
anyone, possibly even root.  On the other hand, by limiting the user  
to a non-privileged account, any such intrusion can be contained  
because of limitations to the access rights of the web service.