| 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 what rows of data an individual database user can access. Traditional database security only provides the ability to control the permissions of a user at the table level; that is, can they read, write or delete data in a particular table? 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 database queries. The database ensures that users can only view and update data they are authorized to access.
Given that Row Level Security is 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 perspective.
Database / Application Users
It is important to understand the distinction between database users and application users. The introduction states that visibility levels are based on Database User permissions. In the Sparx Systems Pro Cloud Server environment, each Database Manager is defined with all of its connection details (including the user ID 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 addition 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 column stores the visibility level that is required to view or update the corresponding 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 Browser window 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, enabling Visibility Levels entails a cost when compared to the same model without Visibility Levels being enabled. Row Level Security in both SQL Server and Oracle imposes extra processing on the database server each time data is selected. The impact of this extra processing on database performance is difficult to estimate, as it depends on the type and amount of data being selected. Enterprise Architect's support of Visibility Levels has been designed with efficiency in mind; however, the performance will inevitably be reduced when Visibility Levels are enabled.