ClassiX^® Information Security System

InstantView^® accesses model object data. This access can be  limited by security objects, which also control the authorization and deletion of an object.

InstantView^® Messages can be locked to prevent access to certain parts of an application (CX_MESSAGE_SECURITY). CX_SECURITY_OPTIONS objects permit and prohibit specific ClassiX^® functions.

It is possible to combine security objects to define access authorizations up to a single data field and/or single objects without a big effort. Security objects have been designed, so differences in reference to universal authorization can be indicated for specific object groups and this specialization can continue recursively.

The system does not check the access authorization, as long as there is no registered security object in ClassiX^®. Provided that the access authorization allows this, another security object can be registered. It is not possible to go back to working without security.

Each security object can be registered in  ClassiX^® by calling its function:

It makes sense to connect a security object with the user object CX_USER. The security object is logged in when calling the function Login() and defines user authorization. The user is described by the CX_USER object.

If the database contains an object of the class CX_MASTER_SECURITY, it already logs in when starting ClassiX^®.

• 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

Access authorization is defined for all objects in a class. Reading- and writing authorization applies for all class data fields (including Dynamic Data Fields). With CX_ATTRIBUTE_SECURITY objects, it is possible to define differing rights for a specific access path: field accessExpressions.

CX_CLASS_SECURITY objects describe access authorization for an object set. The data field specializations refers to (dependent) security objects with differing subset definitions (e.g. derived classes or selected class entities). Dependent security objects are only evaluated, if the higher-level class can already provide a statement.

Security objects with differing subset definitions (e.g. for derived classes or selected class entities). The dependent security objects are only evaluated if the higher-level object could already provide a statement.

Example:

There are classes A, A1, A2 and B. A1 and A2 have been derived from A :

A CX_CLASS_SECURITY object for A - Bit flags[4] is 0 - describes access authorization for all objects of A, A1 and A2: object set M_A. There should be a different authorization for objects of A1 (amount M_A1). Since M_A > M_A1, the according security object describes a specialization and can be dependent to the security object for A. It is the same for a CX_OBJECT_SECURITY object, which refers to certain A1 entities: M_A > M_A1> M_Objects. It is senseless though, to understand a security object of the class B as an object specialization for A: M_B is no subset of M_A.

Class CX_OBJECT_SECURITY

While CX_CLASS_SECURITY objects describe the authorization of all objects in a class, CX_OBJECT_SECURTIY objects can describe authorization for specific objects.

Class CX_ATTRIBUTE_SECURITY

CX_ATTRIBUTE_SECURITY provides elements for the classes CX_CLASS_SECURITY and CX_OBJECT_SECURITY to describe authorization for single data fields.

The field name is not only for a data field name, but also to enter an access path. Additionally, function calls and indices are generalized as follows:

Leaving out the function parameter:

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

the object applies for all InstantView^® paths with an expression as it is shown above, no matter which parameters have been specified for the call Foo(). However, if

However, if function parameters are specified in the CX_ATTRIBUTE_SECURITY object, it only describes paths with an identical expression.

Leaving out indices such as in:

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

the object describes all access authorization with paths as they are shown above with any index specification. If an index is specified in the CX_ATTRIBUTE_SECURITY object, it only applies to access paths with this exact index.

Examples:

Class CX_SECURITY_SET

These objects pool CX_CLASS_SECURITY-, CX_OBJECT_SECURITY- and CX_MESSAGE_SECURITY objects as well as other CX_SECURITY_SET objects.

CX_SECURITY_SET is supposed to be a security object pool for objects that describe access authorization for disjunctive object sets. Therefore, a linkage specialization via data field specializations does not exist. Instead of a subordination via specializations, it is also possible to pool general and specific descriptions in a security set, if the securityObjects order guarantees, that specific objects are always in front of rather general ones.

Example:

There are the classes A, A1, A2 and B. A1 and A2 have been derived from A, while B does not depend on A:

Acces to the objects in class A, A1 and B is defined with CX_CLASS_SECURITY objects. For some A1 entities, there shall be a different sort of authorization  (CX_OBJECT_SECURITY). This can be accomplished as follows:

• There are only security objects for class A and B in the security set. The specialization for the derived class A1 is dependent to the general specification for class A. The CX_OBJECT_SECURITY object in turn is dependent to A1:

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

Both variants are equal - except for their time response. In the first case, there are two security objects involved in controlling access to objects of the class B, in the second case it is four.

Class CX_MESSAGE_SECURITY

This object can be used to control the access to certain application parts. If the CX_MESSAGE_SECURITY object is logged in (directly or as part of a  CX_SECURITY_SET object), all Messages with their name mentioned in messages are locked. This also applies for the definition of new messages. Whether a message has been locked or not can be checked with TestMsg.

Class CX_SECURITY_OPTIONS

The following bits are allocated so far:

Class CX_MASTER_SECURITY

There is maximum one object like that. Its existence prevents any access to database data with InstantView^® methods without logging in successfully before. This restriction can be avoided when knowing the password for the master security object.

If the database contains  CX_MASTER_SECURITY object, this object is activated when starting  ClassiX^®. In the first security test, the master security object sends the Sytstem Event MASTER_PASSWORD and expects the return of a password. Reacting to this set and answering with the correct password causes complete access authorization. Otherwise it is not possible to access the database at all. It is only possible to access certain functions to write a login routine with InstantView^®.

CX_USER::Login() changes the status of an existent master security object, which now permits everything. Since the login function at the same time activates the security objects that belong to the user, from this point in time exactly this authorization is valid for the special user.

An active and not unlocked master security object

• refuses the writing authorization for all access paths, with one exception: the access path only consists of one single call of a function starting with _Login
  
• permits all messages.

A CX_MASTER_SECURITY object can be put into the database with ClassiX^® utility cxgosr.exe  and the according password (when generating - Flag /Mpassword).

A CX_MASTER_SECURITY object cannot be generated with InstantView^®.

Information: Read more about the classes CX_CLASS_SECURITY, CX_ATTRIBUTE_SECURITY, CX_OBJECT_SECURITY, CX_MESSAGE_SECURITY, CX_SECURITY_OPTIONS in the CyberEnterprise^® documentation. More information on user access authorization
in the AppsWarehouse^® documentation.