WebProtege and user accounts

[Shahim Essaid]

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.


1. WebProtege needs read access in addition to list access before it can
show the project names. This is different from the Protege client setup.
2. 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.
3. 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.
4. 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.
5. 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?

Thanks,
Shahim

[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.

Post by Shahim Essaid
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-***@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/protege-discussion

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

[Shahim Essaid]

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.

Post by 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.
Hello,

Post by Shahim Essaid
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
https://mailman.stanford.edu/mailman/listinfo/protege-discussion
http://protege.stanford.edu/doc/faq.html#01a.03

[Timothy Redmond]

Post by Shahim Essaid
Is this how WebProtege build 200 is supposed to behave?

I am going to talk about where things are going. I think that this is
what you probably want to hear and it would take some extra work to
figure out what the svn trunk is doing. (The cutting edge development
is on a branch that is going to be merged into trunk soon).

Post by Shahim Essaid
WebProtege needs read access in addition to list access before it can
show the project names. This is different from the Protege client setup.

The webprotege user is going to be pretty much all powerful. He will
only run on the tomcat host and he will be responsible for ensuring that
policy is enforced.

Post by Shahim Essaid
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.

This has been fixed but I don't know if the fix made it into the trunk.
I am pretty sure it didn't. What will happen is that web protege
session take on the user identity in some restricted sense. Many
plugins, including the change management will see this identity and use
it. So change tracking will show the correct user. Policy decisions
will still require some extra checking.

Post by Shahim Essaid
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.

Policy checks are done on the tomcat server.

Post by Shahim Essaid
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.

This sounds like a bug.

By the way, the protege team knows that any policy that is enforced on
the client will be very weak. Security policies must be enforced on the
server. Sometimes policies that are enforced only on the client are
useful though. They are not there so much to prevent malicious behavior
as to help users to avoid mistakes. In the Protege client-server, there
are some cases where policy is enforced on both sides. The server side
to prevent malicious intent and the client side to give the right user
experience. I think that the Protege client-server write-access control
policy works this way actually.

Post by Shahim Essaid
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.

Yes.

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

No it does not use the Java SE security infrastructure much. We looked
into this in the past because there was a requirement that we have a
pluggable authentication scheme. If this requirement comes back I will
probably use the java gss api capabilities.

Post by Shahim Essaid

I don't think that enabling and disabling buttons in the user
interface is the best way to enforce privileges.

Yes this is not a good way to enforce policy. Policy should be enforced
on the server. The current plan is that policy will be enforced on the
tomcat server (not on the Protege Server if one exists).

-Timothy

Post by Shahim Essaid
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.
1. WebProtege needs read access in addition to list access before
it can show the project names. This is different from the
Protege client setup.
2. 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.
3. 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.
4. 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.
5. 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?
Thanks,
Shahim
_______________________________________________
protege-discussion mailing list
https://mailman.stanford.edu/mailman/listinfo/protege-discussion
Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

_______________________________________________
protege-discussion mailing list
protege-***@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/protege-discussion

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03