The powerful security functions offered by openUTM are also available in cases where several UTM applications interact via server-to-server communication with distributed processing.
System access control through logical access points
UTM applications can only interact with each other if logical access points have been defined in each application for the remote partner applications (from the point of view of the application). These access points are known as (OSI) LPAP partners (see also "System access control (identification and authentication)").
If you are involved in distributed processing via OSI TP, you can also use the UTM user concept globally (see "System access control (identification and authentication)").
Data access control with distributed processing
The openUTM lock/key code concept and the access list concept are also available for distributed processing. The security measures are defined when generating the applications.
Security measures in the job-submitting application:
When generating an application, you define which services of a remote partner application are to be accessible. This is achieved by defining a local transaction code (LTAC) for each remote service to be used. As a rule, the application cannot access services for which LTACs have not been defined.
If you wish to impose additional data access control, you can provide the individual LTACs with lock codes and access lists. A service of the local application can only request a remote service if the user who started the local service has the appropriate key codes.
Security measures in the partner server application:
In the partner server application, the job-submitting application is assigned a key set. The service requested by the job-submitting application is started only if this key set contains a key code that matches the lock code or the access list of the requested service.
To access a remote service, therefore, the local application must match the lock code or the access list of the LTAC. The key set assigned by the partner server application to all requests from the job-submitting application must also contain a key code that matches the lock code or the access list defined in the partner server application.
Example: Lock/key code concept for distributed processing
Figure 35: Data access control with the lock/key code concept for distributed processing
In the example shown in figure 35, server-to-server communication between application A and application B is possible, since an LPAP partner has been generated in each application for the respective remote application. In application A, LTACs have been generated only for the remote services SB2 and SB3. Service SB1 is therefore not available to application A. A user that signs on to application A under the user ID “UA1” has the key code 1, and can therefore access service SA1 in application A.
Since the user also has the appropriate key codes for the two LTACs, service SA1 can request services SB2 and SB3 via these LTACs. The key set assigned by application B to all requests from application A contains appropriate key codes for services SB2 and SB3. All requirements are thus fulfilled in the configuration of both application A and application B: service SA1 started under user ID UA1 in application A can access services SB2 and SB3 of application B.
Example: Access list concept for distributed processing
Figure 36: Data access control with the access list concept for distributed processing
In the example shown in figure 36, server-to-server communication between application A and application B is possible because in both of the applications there is an LPAP partner generated for the remote application. In application A, LTACs are generated only for the remote services SB2 and SB3. The service SB1 thus cannot be used from application A.
A user who signs on to application A under the user ID “UA1” has the role “1”. This allows the user to use the service SA1 in application A. Because the role “1” also permits access to the two LTACs, the service SA1 can request the remote services SB2 and SB3 via these LTACs. In application B, the LPAP has the key “6” for application A, which permits the services SB2 and SB3 to be called.
All the prerequisites are thus fulfilled to allow the service SA1 started under the user ID UA1 in application A to access the services SB2 and SB3 of application B. The same applies by analogy when the user UB1 wants to access the service SA2 in application A via the service SB1.