Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.
| 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 introduction 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, the user identified in the connection details, that visibility levels are based on.
This concept is not to be confused with Enterprise Architect model users; that is, 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 DBMSs 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 (that is, 1 to 20); however this can easily be adjusted by manually 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, representing the default value; it implies that all database users (even those without an assigned visibility level) can view or update records of this level.
The Drawback
As with most things, the Visibility Levels functionality comes at a cost when compared to the same model without Visibility Levels enabled. Both SQL Server's and Oracle's Row Level Security functional imposes extra processing on the database server that needs to be performed whenever data is selected, this extra processing takes time, how much time depends on the type and amount of data being selected, so it is very hard to estimate. Sparx System's implementation of Visibility Levels has attempted to design its solution in the most efficient way possible however it is unavoidable that models with Visibility Levels will perform slower than models without.