Data access control with distributed processing

You can use the data access control mechanisms of openUTM with distributed processing. The protection methods are specified when the applications are generated. A distinction is made between the job-submitting and job-receiving service.

Protection methods for job-submitting services

When generating an application you generally initially specify which services of a remote partner application may be called. For each remote service that is to be used you must agree an LTAC local transaction code (LTAC statement). Access is generally denied to remote services for which no LTACs have been agreed.

In order to further graduate the data access control you can also assign lock codes to individual LTACs (see "Lock/key code concept") or use access lists (see "Access list concept").
A service of the local application can only address a remote service if the service was started under a user ID (KCBENID) and from a client (KCLOGTER) that have the appropriate access permissions.

LTAC statement in section "LTAC - define a transaction code for the partner application" The following operands are used to define which services of a remote partner application may be called and which access authorizations are placed on the LTAC. The operands ACCESS-LIST and LOCK are mutually exclusive.

• ltacname

  Name of a local TACs (LTAC) for the remote service program.

• ACCESS-LIST=

  Name of an access list. In order to be able to start the remote service program the key set of the user of a local application must have been assigned at least one of the roles defined in the access list (as defined in the USER statement).
  The access list must be defined using a KSET statement.

• LOCK=

  Definition of the lock code for access to the remote service program. A service of the local application can only address this remote service if the local service was started under a user ID (KCBENID) and from a client (KCLOGTER) that have the appropriate access permissions.
  ACCESS-LIST and LOCK cannot be specified simultaneously.

If you enter neither ACCESS-LIST nor LOCK then the LTAC is not protected and any user of the local application is able to address the remote service program.

Protection measures for job-receiving services

You protect job-receiving services by assigning a key set to the logical access point of a partner application (LPAP or OSI-LPAP). Only if this key set contains a key code or access code that corresponds to the lock code or access list of the requested service is it possible for the process requested by the partner application to be started.

In order to be able to access a remote service, the service that is being called must be generated with a TAC and the following conditions must be fulfilled:

• LU6.1 connections:

  The key set for the partner as defined in LPAP ...,KSET= must contain a key code that corresponds to LOCK= or ACCESS-LIST= of the TAC.

• OSI TP connections:

  • If a partner attempts to sign on without a user ID, then the key set defined in OSI-LPAP ...KSET and OSI-LPAP ...,ASS-KSET= must contain a code that correspond to LOCK= or ACCESS-LIST= of the TAC.

    The access authorizations are derived from the intersection of the key sets of KSET= and ASS-KSET=. Thus KSET= should always be a superset of ASS-KSET=.
    You can define suitable restrictions on the key set defined with OSI-LPAP ...,ASS-KSET to ensure that specific TACs cannot be called unless the partner specifies a real user ID.

  • If a partner attempts to sign on with a real user ID, then the key set of this user ID and that defined in OSI-LPAP ... KSET= must contain a code that corresponds to LOCK= or ACCESS-LIST= of the TAC.

  This also applies to a client/server link with OpenCPIC.

For more detailed information about data access control with distributed processing see openUTM manual “Concepts und Functions”.