[protege-discussion] Restricting access to slots and classes based on user roles

[Tania Tudorache]

Ron,

There are different ways of controlling the access to the ontology 
components.

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

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.

Tania



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
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>
>