Policy for write access for certain instances only

Post Reply
wgoebl
Posts: 20
Joined: 09 Dec 2011, 11:08

Hi,

we think of installing essential/protege in Client/Server mode (multi user installation).

A must have is access control like
"User A is allowed to edit Application "A" and instances of class "Software Component" that belong to application "A" .

It is a must have because we have "Application Owners" that are responsible for maintaining "their" applications and related artifacts like components.

In proteges Client/Server Tutorial I found "Write Policies" but as far as I understand it is only possible to assign it for the whole ontology (not only for certain instances).

How doese essential adress this issue?

regards
Wolfgang
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Wolfgang.

You're right, Protege does not provide instance-level access control.
The policy management capabilities of Protege operate at the Project level rather than the instances of classes or instances themselves in the Project.

This is a certainly a familiar requirement but presents a very difficult access control management issue. To achieve the capability to meet what you describe would mean that you would need to manage the access control rights of every user to potentially every instance in the repository.

Depending on the particular model, access control at the class level might be OK but other requirements may need specific instances to be managed - and of course the content in the repository (Project) is changing all the time and there are often thousands of instances! You can foresee scenarios where it takes more time managing access control than managing the content itself.

The other dimension to this is the highly-connected nature of everything in the repository - and this is also a big challenge in the Essential Viewer. Some access control requirements might mean not only that I cannot change specific instances but also that I cannot even see them. This could lead to a range of problems with the integrity of the repository.

So, how do we approach these kinds of requirements with Essential Architecture Manager?

In terms of the modelling side, in Protege, the user community is far smaller than the Essential Viewer side - and so access is already controlled to some extent. However, we are working on projects where groups within an organisation must have "their own" repository. We implement this by setting up a federated set of repositories, each with their own limited access. Protege provides the ability to pull these separate repositories together using its Project Include capability to provide an consolidated view to potentially an even smaller community. Clearly, governance processes are required around shared elements but our integration tools provide the mechanics for moving shared items between the federated repositories. We are also looking into alternative ways of managing such a federated repository (alternative to the Project-Include approach) to improve the ease of use.
However, managing the access control on an instance-by-instance or instance-by-class (and combinations) is now much simpler.

In the Essential Viewer side, you can have as many instances of the Viewer as you need and define access control to each one of those. Again, the highly inter-connected nature of the information that is presented in the Views makes it quite impractical to manage instance-level access.
A simple to manage approach, however, is to control the Views that are available in each of the VIewer environments and ensure that Views that could show sensitive information etc. are only available in Viewer environments that are secured in some way.

Having said that we can easily define taxonomies within the repository to classify certain elements and control the conditions or when they should (or should not!) be rendered. And this is something that we do for relevance (rather than access control) reasons in some of our Views. e.g. classify certain groups of elements in the repository by an organisational taxonomy and then within the Views only display elements that are classified accordingly.

Hope this gives you some ideas about how to meet your requirements. There are some options depending on your specific requirements but the challenge for managing individual user access on an instance-by-instance basis is not to be underestimated. As I say, we typically work with repositories with 20,000+ instances.

I'd be very happy to explore the options for meeting your requirements for multi-user mode.

Jonathan
Essential Project Team
Post Reply