Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] WebProtege and user accounts

Shahim Essaid sielists at
Fri Oct 2 12:26:33 PDT 2009

I am not exactly sure how Protege handles authentication and authorization
but I don't think it uses the Java SE security infrastructure/service.

In my case, I have Protege server running using my Linux account and
WebProtege is hosted in Glassfish also running as my Linux account.  My
impression is that Protege accounts have nothing to do with OS accounts.  A
user will have to break into the WebProtege application in order to have my
OS privileges and if they are able to do that then it doesn't matter which
Protege account WebProtege is using.

What I am confused about is how WebProtege is handling Protege accounts.
When the Protege thick client is used to connect to the server the user
enters the user name and password before a server connection is established
but WebProtege has a connection before a user is logged in.  I understand
why this is necessary for WebProtege (to show a list of projects) but
WebProtege should establish a new connection for the specific logged-in user
so that proper permissions are enforced and changes are properly tracked
according to who made the changes.  Giving WebProtege the highest
permissions (the way it is now so that WebProtege can perform any actions on
behalf of the actual user) is actually a riskier situation.  As I said in my
first email, I was able to make changes to the ontology even after I logged
out of WebProtege.  This should not be possible once a user is logged out
but it is in this case because the WebProtge account has the privileges to
do that and WebProtege somehow accepted the edit requests from the logged
out user (because the edit buttons where still active). I don't think that
enabling and disabling buttons in the user interface is the best way to
enforce privileges.

On Fri, Oct 2, 2009 at 11:58 AM, Thomas Russ <tar at> wrote:

> 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.
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at
> Instructions for unsubscribing:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the protege-discussion mailing list