Dr. Paul Dorsey
Dulcian, Inc.
Security in the BRIMä environment is included in both the UML-based and State Transition Engine portions of the system.
All security is based on the concept of a “UML Rule,” which is equivalent to an entire project created in BRIM™. Users and security tokens (roles) are not global to the system but are to be considered in the context of a specific UMLRule.
UML security is token-based. This is the same as the idea of a role in most systems. A user is given one or more tokens. Users are entered into the system in UMLUser, and security tokens are created in UMLSecure. Tokens are given to users in the UMLUserSecure table.
Classes are stored in UMLRuleClass. Classes are declared as secure by assigning the keyword “Secure” to the class. This is stored in UMLKeyWord. Unless a class is flagged as secure, anyone can do anything to it. By default every user has privileges to all objects in all classes. Once a class has been flagged as secure, no one has any rights to do anything to the class until they are explicitly granted.
Users are not granted rights directly to a class. Instead, tokens are given rights and those tokens are given to users. Tokens can be thought of as keys to the secure parts of the rule.
Tokens are granted privileges by associating them with a class and giving them explicit rights to the class. This is done in the UMLClassPriv table. Rights are granted to a particular token by placing a ‘Y’ in the appropriate column.
The available privileges are:
|
Privilege |
Column Name |
Description |
|
Edit |
edit_YN |
User can edit existing objects. SQL update commands will execute. |
|
Display
|
display_YN |
User can view existing objects. SQL select commands will execute. |
|
Create
|
create_YN |
User can create existing objects. SQL insert commands will execute. |
|
Delete |
delete_YN |
User can delete existing objects. SQL delete commands will execute on classes without history. UML.Remove_object will work on classes with history. |
|
Inactivate |
inactivate_YN |
User can delete existing objects on classes with history. SQL delete commands will execute on classes with history. |
|
Reactivate
|
reactivate_YN
|
User can reactivate inactivated objects on classes with history. UML.reactivate will work on classes with history |
These rights act as “gatekeeper” rights. Rights cannot be extended by any other security privilege. For example, if a user has “edit” as a column privilege but does not have “edit” privilege to the table in general, the column “edit” privilege will be ignored.
UML Class privileges may be refined by UML column privileges. These are stored in UMLColumnPriv, which is a child table to UMLClassPriv. Column privileges are only defined in the context of an existing UML Class privilege.
Note the use of the term “column” rather than “attribute” privileges. This is because you can set privileges on all columns that arise in the BRIM™ relational implementation of a class. This includes native attributes, inherited attributes and all relevant association foreign keys.
There are only 2 privileges for columns as shown in the table below.
|
Privilege |
Column Name |
Description |
|
Edit |
edit_YN |
User can edit this column. SQL update commands will execute. Insert commands allow this column to be populated. |
|
Display
|
display_YN |
User can view this column. SQL select commands will execute. |
Valid values for these columns are ‘Y’ or ‘N’. The default value is ‘Y’. A missing row for any column is also interpreted as the value ‘Y’. UML column privileges are used to revoke privileges granted at the class level.
It is possible for a column privilege to effectively negate
a class privilege. If you
have a UML class privilege of “create = Y” but The UML column privilege on a
column is 'N', this means you can do an insert but you cannot populate the
column. Therefore, if the column is
required, this would effectively negate your ability to create the object.
Security
enforcement in the engine is for Insert, Update and Delete functionality only. Select * from <table>
Security for business event classes is the same as for any class. Classes can be given security in exactly the same way. An additional type of security specific to business event classes is also included.
Such security is token-based; however, it is related to the behavior of the object in a particular state executing the manual processing event. The idea is that if an object is in a state, your STE column-level privileges will determine what fields you can see or edit when operating in the manual processing event.
This information is stored in the STEColumnPriv table, which
is a child table to UMLClassPriv. The privileges
are set the same as for UML column privileges.
The only difference is that you can set the privileges for the class and
any composition child classes at the same time.
For example, if you have a purchase order with an associated workflow, for
a purchase order in a particular state, you can set privileges for both the
Notes:
To be able to set STE Column Privileges, a business event class must first be set as “Secure” and must have a token with appropriate privileges assigned to it.
The BRIM™ engine does not enforce STE column privileges. They are enforced by the applications. See the application development guide for more details.
Columns may be required in a particular state’s manual processing event. This would mean that the user may not submit the event for processing if all required fields are not entered.
Notes:
STE-required columns are not token dependent. If a column is set as required then it
The engine does not enforce STE required columns. They are enforced by the applications. See the application development guide for details.
If a user has more than one token, then they will get a union of all possible privileges. So, if a user is allowed to edit columns A,B, and C because of one token, and can edit columns C,D because of another token, then they will be able to edit any of columns A,B,C,D. This is true for all security types.
Once these privileges are assigned, they are immediately available. Security tables are accessed prior to the table access so that no compilation of security is required.
Because of inheritance, you may end up giving the ability to indirectly modify a table. For example, assume that you have edit privileges on the Employee table. If the user modifies objects in the Employee table they may automatically also modify objects in the Person table if the Employee table is in the same generalization path as the Person class. This will be true even if the Person class is secure and the user does not have any tokens with the Edit privilege on the Person class.