WebOffice usermanagement System Architecture

To understand how WebOffice usermanagement works in combination with WebOffice 10.9 SP1, take a look at the figure below. User management administration work is performed by two applications involved in maintaining the rights repository:

WebOffice author

UserManagement Admin Web

WebOffice author not only manages the WebOffice 10.9 SP1 project and application configuration, but also stores basic data (like map service entries, project entries, layer entries etc...) into the user management database. The connection to a user management database has to be defined in the Basic Settings. On the other hand the UserManagement Admin Web application serves as an administration tool to manage the role or group definitions (such as group rights for projects, restrictions for topics and templates, etc...) in the rights repository. The connection parameters for UserManagement Admin Web are defined in the file web.config.

 

Finally, WebOffice 10.9 SP1 reads the permissions from the user management database using JDBC to give users access to projects, tools, data, etc. according to the configuration in the user management database. The connection to a user management database has to be configured in the Application Configuration.

 

WebOffice usermanagement System Architecture

WebOffice usermanagement System Architecture

Implementing Role Based Security

First of all you need to analyze carefully which different user roles you want to implement. You should, e.g. set up an excel sheet that contains all relevant information. This will serve for later documentation as well. An analysis is also necessary to efficiently set up and manage your WebOffice usermanagement rights repository efficiently.

In order to be able to minimize administrative work you should make use of a multi-level access rights approach: From course grained control towards fine grained rights control. This way you will be able to implement your needs with a minimum of work and time.

 

WebOffice usermanagement - Levels of access control

WebOffice usermanagement - Levels of access control

 

As in the figure above, there are 3 different levels of access control:

WebOffice 10.9 SP1 project level (level 1)
At this level you define whether a user role is allowed to access a project at all or not WebOffice 10.9 SP1 project at all or not.
Check all available WebOffice 10.9 SP1 projects regarding this aspect.

Tool level (level 2)
Analyze and check at this level only those WebOffice 10.9 SP1 projects that are authorized to access the previously defined role.
On this level you need to determine which toolbar tools are available for the role you currently specify. Each individual tool is stored in an WebOffice 10.9 SP1 application role.

Layer level (level 2)
Analyze and check at this level only those WebOffice 10.9 SP1 projects that are authorized to access the previously defined role.
In a further step, you can analyze those layer aspects that are relevant for the available tools. For example, if the tool Edit is not available, then you do not need to consider editing rights for the layers.
At this level, you specify which of the following elements should be available for the previously specified user role:

oMap Services

visible/invisible

oLayer Groups

visible/invisible

oLayer

visible/invisible

searchable (search based on attributes)

available for identify- or select operation (search based on spatial location)

editable (create object, edit, delete)

Object level (level 3)
Analyze and check at this level only those WebOffice 10.9 SP1 projects that are authorized to access the previously defined role.
In a further step, you can analyze those layer aspects that are relevant for the available tools. For example, if the tool Edit is not available, then you do not need to consider editing rights for the layers.
Furthermore, on this layer you will consider only those layers that are visible and on which you can either search, select or edit.
Lastly, at this level you can define access to specific objects of an available layer for the previously defined role. You only need to analyze those layers for which at least part of the objects should NOT be accessible/available for the role.