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

Timothy Redmond tredmond at stanford.edu
Mon Oct 5 15:40:49 PDT 2009



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

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

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

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


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

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


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

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


On Fri, 2009-10-02 at 09:57 -0700, 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. 
> 
>      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
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> 
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03




More information about the protege-discussion mailing list