Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Access rights and data access control

Administration authorization is defined in the UTM generation. It is not bound to a certain person (user ID) or to a specific location (console). Administration can be carried out through any LTERM partner, regardless of whether this is in the form of a terminal, UPIC Client, HTTP client or TS application. Furthermore, you can assign administration authorization to partner applications of your UTM application, allowing you to administer each your UTM applications from another application. In particular, you can administer a number of applications running on different computers centrally from one application (see the chapter "Central administration of several applications").

In addition to general security functions (access via user IDs and the lock/key code and access list concept), openUTM also provides a special authorizations concept specially for administering a UTM application via the program interface KDCADMI and via the administration commands.

Authorization level 1

Users, clients and partner applications can call administration services which merely query, collate and analyze the information offered with regard to objects and application parameters (i.e. which only require read access to the configuration data) without any administration authorization (also referred to as administration privileges). This assumes that you have assigned the authorization level ADMIN=READ to the transaction codes via which these administration services are called.

ADMIN=READ can only be specified in the following cases:

  • for the commands KDCINF, KDCINFA, KDCHELP and KDCHELPA

  • for transaction codes which start program runs in which the following calls are issued:

    • KC_GET_OBJECT

    • KC_ENCRYPT with subopcode1=KC_READ_ACTIV_PUBLIC_KEY or subopcode1=KC_READ_NEW_PUBLIC_KEY

    • KC_SYSLOG with subopcode1=KC_INFO

In such cases, program units and transaction codes can be generated as follows:

  • BS2000 systems

    PROGRAM ADMPROG,COMP=ILCS
    TAC ADMTAC,PROGRAM=ADMPROG,ADMIN=READ
  • Unix, Linux and Windows systems

    PROGRAM ADMPROG,COMP=C
    TAC ADMTAC,PROGRAM=ADMPROG,ADMIN=READ

Authorization level 2

Administration services which modify the configuration, the application data and object properties (i.e. which require write access to the configuration data) can only ever be called by user IDs and partner applications with administration privileges (PERMIT=ADMIN). The transaction codes for these services must be configured with ADMIN=YES.

In these cases, program units and transaction codes must be generated as follows:

  • BS2000 systems

    PROGRAM ADMPROG,COMP=ILCS
    TAC ADMTAC,PROGRAM=ADMPROG,ADMIN=Y
  • Unix, Linux and Windows systems

    PROGRAM ADMPROG,COMP=C
    TAC ADMTAC,PROGRAM=ADMPROG,ADMIN=Y

The following transaction codes must be generated with ADMIN=Y:

  • all administration commands, apart from KDCINF[A] and KDCHELP[A]

  • transaction codes which start program runs in which KDCADMI calls other than KC_GET_OBJECT,
    KC_ENCRYPT with subopcode1=KC_READ_ACTIV_PUBLIC_KEY or subopcode1=KC_READ_NEW_PUBLIC_KEY or
    KC_SYSLOG with subopcode1=KC_INFO are issued:

Other program units which call transaction codes with authorization level 2 must run under a user ID which has administration privileges. 

Example

You can write an administration program which, if it is called by the transaction code ADMTAC1, merely queries whether a printer is connected to the application. If the same program is called with the transaction code ADMTAC2, the program unit again uses KC_GET_OBJECT to query whether the printer is connected to the application. However, if the printer is not connected to the application, the program unit will then also request that a connection be established to the printer (KC_MODIFY_OBJECT). ADMTAC1 can be called from any user ID and from any partner application. ADMTAC2, however, can be called only from user IDs and partner applications that have administration privileges.

The KDCDEF generation would consequently look like this:

  • BS2000 systems

    PROGRAM ADMPROG,COMP=ILCS
    TAC ADMTAC1,PROGRAM=ADMPROG,ADMIN=READ
    TAC ADMTAC2,PROGRAM=ADMPROG,ADMIN=Y
    
  • Unix, Linux and Windows systems

    PROGRAM ADMPROG,COMP=C 
    TAC ADMTAC1,PROGRAM=ADMPROG,ADMIN=READ
    TAC ADMTAC2,PROGRAM=ADMPROG,ADMIN=Y
    

You can then allocate access authorizations in detail using the lock/key code and access list concept.