Protege Client Server Tutorial Configuration
Protege Server Configuration
This page describes the configuration of the Protege server including: the metaproject, creating users and policies. This page is part of the Protege client-server tutorial.
This section describes how to configure the projects that are available from the Protege server. (Read this section only if you have succeeded in performing the steps from the section Protege Server Setup.
The metaproject, located by default in the
examples/server subdirectory of the Protege installation directory, contains information about which Protege projects are exported, i.e. available to Protege clients, and which users have access to these projects. It also stores policy configurations. Note that the built-in security concerning which users can access which projects is on top of whatever other security your system provides, e.g. a firewall.
Use Protege to open the metaproject and spend some time browsing the class hierarchy. You will find a very simple ontology of users, security, and projects:
How policies work
There are two types of policies supported by the Protege server: project policies and server policies. The project policies refer to the permissions set for a particular project. For example, for the Collaborative Pizza project, a policy may say that only people from the group Pizza Makers are allowed to open this project (other users will not even see it in the project list after login). The server policies apply to the server itself and has associated to it more "administrative" types of permission. For example, one policy might say that only users from the Admin group are allowed to shut down the server.
The policy model represented by the metaproject ontology is very simple and flexible. The idea is that you can attach to a policy controlled object (a project or a server) a set of allowed operations for a certain group. The examples from the previous paragraph are quite clear. You may define your own operations, groups, users, etc. There are some predefined operations that the Protege server enforces in the UI (e.g., the read permission), and we'll talk about them in the Policies section.
Project policies refer to the policies that apply for a particular project. For example, you may restrict the permission of reading and opening a project to a certain group. The project policies are attached to instances of the Project class as show below:
Instances of the Project class will be made available to people identified with instances of the User class.
If you examine instances of the User class, you will find the default Guest user. For the security conscious, your first task should be to delete the Guest user, and any other default users. (Before doing this, you may want to try creating some new users and ensure that they can successfully connect).
If you examine instances of the Project class, you will encounter among others the Newspaper and Collaborative Pizza projects. Note that these are just references to projects that exist on your disk as part of the default Protege installation. Also note that the specified file locations are relative to the Protege installation directory (actually the current working directory) rather than to the location of the metaproject. If you find this confusing, you can always specify the file locations as absolute paths. On a Window machine, for example, you can specify the absolute path as
C:/MyProject/kbs/MyProtegeKB.pprj. If you have other projects that you have created and you want to make them available in the client-server version, you should create instances of these projects in the metaproject. (We recommend making a copy of the metaproject first, just in case!). Remember to configure the policies of the projects (see Policies section below).
Server policies refer to policies that apply to the server itself. Usually the operations in the server policies are more of administrative nature:e.g., shut down the server, shut down a project, etc.
Instances of the Server class represent different server configurations to which you may attach server policies (e.g., who has permission to shut down the server, or which user is allowed to kill other users' sessions). The current implementation only works with one instance of Server, which refers to the current Protege server. So there is no need to create more than one instance of Server. The default metaproject comes with the predefined instance "MyServer" that has some default policies attached to it. You may delete the existing policies or add new ones. It's not a good idea to give to all the users administrative rights on the server. Instead only an Admin group should have these privileges.
After editing the metaproject, save it and restart the Protege server (changes only take effect after the Protege server restart). There is currently no way for the server to read an updated metaproject (we may provide this in the future). You should now be able to see the results of your changes, such as additional projects and users, when you connect from a new client.
The main classes of the metaproject ontology are explained briefly below:
- User - instances of this class will be the actual users who can login into the Protege server. A user has a user name, a password, a description, and can belong to one or more groups (or none). To create a new user, select the class User and create a new instance and fill in the slots (property) values.
- Group - instances of this class are the groups available in the Protege server. A group has a name, a description and members of type User. If you add a user to a group, the inverse relationship is create automatically (e.g., John is in the Editors group, then the Editors group will have as a member John).
- Operation - instances of this class represent the operations available in the Protege editor (or in your own application that accesses the Protege server). An operation has a name and a description. The metaproject comes with some predefined operations: Read, Write, DisplayInProjectList.
- GroupOperation - instances of this class associate one or more groups of users with a set of operations. A predefined GroupOperation instance in the metaproject is the
World can Read and Write. The group operations are not useful as stand alone instances, but they are associated to projects. For example, to the Collaborative Pizza project, we associate the group operation
World can Read and Write, meaning that all the users who open the Collaborative Pizza project from a Protege client, will be able to read and write this project.
- PolicyControlledObject - it is just a super class for all the classes that can have policies attached to them, such as Project or Server. No need to do anything with this class.
- Project - the most important class. This is where you will start by creating project instances and for navigation. The Project instances represent actual projects stored on the server side. These projects will be available to Protege clients that connect to this server. A project has:
- a name - it may contain spaces, this is what is displayed in the available projects list on the client
- a description - some text or documentation about the project
- a location - can be relative to the Protege server installation directory, or absolute
- policies - are associated to the project as instances of GroupOperation
- an annotation project - is optional. If you want to use Collaborative Protege or the Change Tab on the server, you need to configure this project. Step-by-step instructions are available here. For example, the Collaborative Pizza has an associated annotation project called Collaborative Pizza Annotations (also a "normal" project; an instance of Project class)
- Server - the second most important class. An instance of Server represents an actual Protege server to which you can attach policies. The current implementation does not support multiple instances of the Server class, so if you want to add policies to the server, make sure they are all attached to one (and the only one) instance of the Server class (the name of the instance is not important). A server has similar properties to a project:
- a name - it may contain spaces
- a description - some text or documentation about the server
- a host name - the hostname of the server (e.g., smi-protege:stanford.edu:5200). In current implementation, this field is ignored, so you can leave it blank.
- policies - are associated to the server as instances of GroupOperation
Predefined and enforced policies
|Read||The operation of reading an ontology on the server. This operation is enforced in the Protege clients and in the API. If a client does not have the read right on a project, she will not see in the client the project in the available project list after logging in the Protege server.||Yes|
|DisplayInProjectList||If a project does not have this operation associated to it, then the project will not be displayed in the available project list when a user logs into the server. This operation is useful, if you want to hide certain projects from the available projects list for the users, but you still want to be able to read them. A good example is the changes and annotations project that is used by collaborative Protege. You would not want the users to see the annotations project and open it directly in the client.||Yes|
|Write||The write operation on an ontology. In the current version, this operation is not enforced in the Protege UI or API. We may provide this functionality in future versions.||No|
Create new users from the client
By default, the server will disallow the creation of new users in the "Login to Server" panel when clicking on the "New user" button. To allow the creation of new users by clicking on the "New user" button on the client, add to the
protege.properties file the following line:
After editing the protege.properties, you need to restart the Protege server, for the changes to take effect.
Read more about the Protege multi-user support in the Protege client-server tutorial.