Search Mailing List Archives
[protege-discussion] Restricting access to slots and classes based on user roles
ron.schultz at vectorsgi.com
Sun Mar 4 12:00:33 PST 2007
I am reviewing nci_june15 and I am wondering what portions of this have been integrated into Protégé 3.3. Is it worthwhile (from a time and effort viewpoint) for me to pull the AccessRightsManager into Protégé 3.2 for my sample application, or should I SVN checkout Protégé 3.3 and then pull this into 3.3? Is the AccessRightsManager already in 3.3?
As a side note, is there a tracking mechanism where I can review the features and there status in various builds of Protégé? I have reviewed the Protégé Bugzilla database, but this information does not appear obviously present to me.
From: protege-discussion-bounces at lists.stanford.edu [mailto:protege-discussion-bounces at lists.stanford.edu] On Behalf Of Tania Tudorache
Sent: Wednesday, February 14, 2007 11:59 AM
To: User support for Core Protege and the Protege-Frames editor
Subject: Re: [protege-discussion] Restricting access to slots and classes based on user roles
There are different ways of controlling the access to the ontology
1. One way to do it is to make the access control at the level of the
GUI, meaning that your GUI elements will understand the user roles and
according to them they will get enabled or disabled. This is not hard to
implement and we have done this (details at the end of the email).
However, this means that at the API level, one can do anything, because
the access rights are only enforced by the GUI. But this is enough for
some applications. We have developed a pattern for enabling/disabling of
GUI components which will probably be available soon (in about a month)
in the Protege beta releases.
Using the GUI level implementation helps the implementer better control
the buttons for different actions. The GUI implementation can
enabled/disable a button for an action that is not allowed by the
2. Another way is to do the control at the level of the API. You could
implement a framestore that will understand the access rights and
whenever a not permitted operation is done, an exception can be thrown.
In this way, it is very easy to control the access at the API level, but
you will have some problems at the GUI level. This is because the
exception is thrown only after an operation is attempted. For example, a
user is not allowed to perform a "Create class" operation. However, the
GUI won't know that, so the "Create class" button will be enabled and if
the user presses it, then an exception will be thrown and probably the
user will get a popup with a message that the operation is not
permitted. But, I can see that this can become very annoying for the user.
So, the best solution is a combination of solution 1 and 2 if you want
to control the access both in the GUI and at the API level. This is not
hard to be done.
However, the real challenge comes when defining the semantics and the
propagation rules of the access rights. For example, you define that a
class is read-only for a user. What does this mean? Are the subclasses
also read-only? Can you assign the domain of a slot to be the read-only
class? The problem is that usually the elements of an ontology are very
interlinked with each other and there are always different ways to
achieve the same operation and different modelings that are equivalent.
To compute the "real" rights of a user for a certain operation on a
certain element of the ontology can be very hard and expensive.
I mentioned before that we have already implemented the access rights at
the GUI level on the nci_june15 branch from the SVN repository. We have
developed an AccessRightManager which can give the answer to "Is this
operation allowed for this user on this project?" The GUI elements are
controlled based on these answers. We have also developed the pattern
that I have mentioned for propagating the enabling/disabling of a GUI
component to all the children components. So, for example, if you set
the class form for a class to be disabled (with one method call), this
will be propagated to all the slot widgets that will get disabled too.
Schultz, Ron wrote:
> Has anyone dealt with a requirement to restrict access to classes and slots based on a user role defined within Protégé? I need to support user roles with specific rights (e.g., update, delete, read-only) to specific classes and slots, and I need to ensure that the Protégé Forms enforce these rights. I thought of extending the widgets to provide this degree of control, but I was wondering if I could accomplish this at a lower level within Protégé so that even API users would have to abide by the sames rules. Any pointers or references would be much appreciated.
> Ron Schultz
> [This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy.]
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
protege-discussion mailing list
protege-discussion at lists.stanford.edu
Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
[This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy.]
More information about the protege-discussion