Topics
Prev Next

Visibility Levels

The 'Visibility Levels' feature within Enterprise Architect provides the ability to restrict access to certain sections of a model. Only models hosted by a Pro Cloud Server are able to make use of this feature. Visibility Levels are implemented by taking advantage of the Row Level Security feature included in Oracle 8+ and Microsoft SQL Server 2016 (onwards).

Row Level Security is a security feature that controls which database users can access which rows of data in a database. Traditional database security only provides the ability to control which users have access to read, write or delete data down to the table level. Since Row Level Security functionality is implemented by the database, it is impossible for users to bypass security implemented at the application level, by writing their own scripts or databases queries. That is, the database ensures that users can only view and update data they are authorized to access.

Since Row Level Security is functionality implemented by the database, most of the configuration for Enterprise Architect and the Pro Cloud Server to support it is performed directly in the database without needing to change the application code base, which means there is less to go wrong from an application point of view.

Database / Application Users

It is important to understand the distinction between database and application users.  The above discussion mentions that visibility levels are based on Database User permissions.  In the Sparx System Cloud Server environment each Database Manager is defined with all of its connection details (including the user and password) to a given database.   It is the database user, and is user used in the connection details that visibility levels are based on.

This concept is not to be confused with Enterprise Architect model users, ie the user ID/password that is entered when accessing a security enabled model.  This is an application user. 

Note: Enterprise Architect's model security is not mandatory, whereas all DBMS's require a database user to be defined in order to access data within the database.

How it works

In additional to their normal permissions, database users are granted access to one or more visibility levels.

A new column, VIS_LVL (Visibility Level), is added to 24 critical tables within the Enterprise Architect database. This field stores the visibility level that is needed to view/update this record.

For each of the 24 tables a security policy is defined that ensures each database user only sees records that their assigned visibility level is authorized to view.

Database triggers are then used to maintain the value of the VIS_LVL columns in all tables for all child objects and elements. For example, setting the visibility level of a Package in Enterprise Architect's Project Browser will update the selected Package and all of its children to the entered visibility level.

Note: The base scripts supplied by Sparx Systems support 20 'levels' of security (ie 1 to 20), however this can easily be adjusted by changing the number of rows that are inserted into the T_VISIBILITYLEVELS table at the beginning of the script. Level 0 is a special case, it represents the default value and implies that all database users (even those without a assigned visibility level) can view or update records of this level.

While the supplied scripts create  could be adjusted to support more levels; however, this will need to be done manually.) The visibility levels are cumulative; for example, a user with level 3 can see all level 1, 2 and 3 rows.

Learn more