ClassiX® Information Security System

ClassiX® Information Security System

InstantView® accesses the data of the model objects (reading and/or writing). These accesses can be restricted by security objects. Security objects also control the authorisation to create or delete an object. (A user-oriented overview of user access rights can be found here).

Furthermore, InstantView® messages can be blocked to prevent access to certain parts of an application (CX_MESSAGE_SECURITY), and objects of the class CX_SECURITY_OPTIONS are used to allow or forbid certain functions of the ClassiX® system.

Security objects can be combined to define differentiated access rights down to the individual data field and/or individual object with little effort. The security objects were designed in such a way that, based on generally valid rights, deviations can be specified for certain object groups and this specialisation can be continued recursively.

As long as no security object is logged into the ClassiX® system, the system does not check the access rights. As soon as such a security object is logged in, access rights are checked. If the access rights allow it, another security object can be registered. However, it is not possible to return to the initial state of working without security.

Each security object can be protected by calling its function:

be registered with the ClassiX® system.

It is useful to link a security object with the user object CX_USER, so that the former is logged on when the Login() function is called and determines the rights of the user described by the CX_USER object.

If the database contains an object of the class CX_MASTER_SECURITY, this object is already logged in when the ClassiX® system is started.

• CX_CLASS_SECURITY
• CX_OBJECT_SECURITY
• CX_ATTRIBUTE_SECURITY
• CX_SECURITY_SET
• CX_MESSAGE_SECURITY
• CX_SECURITY_OPTIONS
• CX_MASTER_SECURITY

Class CX_CLASS_SECURITY

flags[0]

flags[1]

flags[2]

flags[3]

flags[4]

Access rights are defined for all objects of a class. The write and read rights initially apply to all data fields (including dynamic data fields) of the class. For certain access expressions, different rights can be defined with objects of the class CX_ATTRIBUTE_SECURITY: Field accessExpressions.

Objects of class CX_CLASS_SECURITY describe the access rights for a set of objects. The data field specializations refers to (subordinate) security objects with different specifications for subsets (e.g. for derived classes or for selected instances of a class). The subordinate security objects are only evaluated if the superordinate object could already provide a statement.

Example:

There are classes A, A1, A2 and B, where A1 and A2 are derived from A:

A CX_CLASS_SECURITY object for A - let bit flags(4) be 0 - describes the access rights for all objects of classes A, A1 and A2: set of objects_MA. Different rights are to apply to objects of class A1 (set_MA1). Because_MA > _MA1, the corresponding security object describes a specialisation and can be subordinated to the security object for A. The same applies to an object of the class A1. The same applies to an object of the class CX_OBJECT_SECURITY, which refers to selected instances of A1: _MA > _MA1>MObjects. On the other hand, it makes no sense to consider a security object for class B as a specialisation of the object for A:_MB is not a subset of_MA.

Class CX_OBJECT_SECURITY

flags[0]

flags[1]

flags[2]

flags[3]

flags[4]

While objects of the class CX_CLASS_SECURITY describe the rights of all objects of a class, CX_OBJECT_SECURTIY objects can be used to define the rights for very specific objects.

Class CX_ATTRIBUTE_SECURITY

flags[0]

flags[1]

The class CX_ATTRIBUTE_SECURITY provides the elements with which objects of the classes CX_CLASS_SECURITY and CX_OBJECT_SECURITY can describe rights for individual data fields.

In the field name, not only the name of a data field but also a navigating access expression can be specified. The following additional generalisations apply to function calls and indexes:

If function parameters are omitted:

. . . a.Foo().b ...

then the object applies to all InstantView® accesses with expressions of the above form, regardless of the parameters specified for calling Foo(). However, if function parameters are specified in the CX_ATTRIBUTE_SECURITY object, it only describes accesses with exactly identical expressions.

If indices are omitted, such as in

. . . a.collection[].b . . .

the object describes the rights of all accesses with expressions of the above form with any index information. If an index is specified in the CX_ATTRIBUTE_SECURITY object, it only applies to access expressions with exactly this index.

Examples:

access[].city

access[0].city

access[0].city

access[x].city

Class CX_SECURITY_SET

Objects of this class are used to combine objects of the classes CX_CLASS_SECURITY, CX_OBJECT_SECURITY and CX_MESSAGE_SECURITY as well as other CX_SECURITY_SET objects.

CX_SECURITY_SET is intended as a grouping of security objects that describe access rights for disjoint sets of objects - i.e. there is no case of specialization for coupling with data field specializations. But it is also possible to combine general and special descriptions in one security set instead of subordination by means of specializations , if the order in securityObjects guarantees that special objects always come before more general ones.

Example:

There are classes A, A1, A2 and B. A1 and A2 are derived from A, while B is independent of A:

Access to objects of classes A, A1 and B are defined with CX_CLASS_SECURITY objects. For some instances of A1, different rights are to apply(CX_OBJECT_SECURITY). Possibilities to realise this are

• Only the security objects for classes A and B are in the security set. The general specification for class A is subordinated to the specialisation for the derived class A1 and the CX_OBJECT_SECURITY object is subordinated to this:
  

• All security objects are directly assigned to the security set. The order of the security objects referring to A and A1 is essential:
  

Both variants are - except for the time behaviour - equivalent. In the first case, two, in the second case four security objects are involved in controlling access to class B objects.

Class CX_MESSAGE_SECURITY

This object can be used to control access to certain parts of an application. When the CX_MESSAGE_SECURITY object (directly or as part of a CX_SECURITY_SET object) is logged on, all messages whose name is mentioned in messages are locked. This also applies to the definition of new messages. Whether a message is locked can be determined with TestMsg.

Class CX_SECURITY_OPTIONS

So far the following bits are occupied:

Class CX_MASTER_SECURITY

In a database, there is a maximum of one such object, and its existence prevents you from accessing the data in the database with the means of InstantView® without a successful login first. However, this restriction can be circumvented if the password of the master security object is known.

If the database contains an object of the class CX_MASTER_SECURITY, this object is already activated when the ClassiX® system is started. During the first security test the Master Security Object sends the system event MASTER_PASSWORD and expects the return of a password.
If this message is responded to and answered with the correct password, full access rights exist.
Otherwise the database cannot be accessed at all. Only the call of certain functions is possible so that a login routine can be written with InstantView®.
The function CX_USER::Login() changes the status of an existing Master Security Object so that it now allows everything.
Since the login function simultaneously activates the security objects belonging to the user, from this point on the rights intended for the specific user apply.

An active master security object that has not been released

• denies read permission for all possible access paths, with one exception:
  the access path consists only of calling a single function whose name begins with _Login.
• allows all messages.

An object of the class CX_MASTER_SECURITY with the corresponding password can be placed in the database with the ClassiX® utility cxgosr.exe (when creating - flag /Mpassword).

An object of class CX_MASTER_SECURITY cannot be created with InstantView®.

Note: Refer to the CyberEnterprise® documentationfor more information on the above classes: CX_CLASS_SECURITY, CX_ATTRIBUTE_SECURITY, CX_OBJECT_SECURITY, CX_MESSAGE_SECURITY, CX_SECURITY_OPTIONS
Refer to the AppsWarehouse® documentationfor more information on user access rights