Unicenter SOLVE:Operations Automation Security
search cancel

Unicenter SOLVE:Operations Automation Security

book

Article ID: 55591

calendar_today

Updated On:

Products

CMDB for z/OS NetSpy Network Performance NetMaster Network Automation SOLVE NetMaster Network Management for SNA NetMaster Network Management for TCP/IP NetMaster File Transfer Management SOLVE:Operations Automation SOLVE:Access Session Management SOLVE:FTS

Issue/Introduction

Unicenter SOLVE:Operations Automation Security

Environment

Release:
Component: SOPMVS

Resolution

The Unicenter SOLVE:Operations product family supports multiple users. It allows very close control over the facilities that each user is allowed to access. This control is managed using the User Access Management System (UAMS). This security facility can operate in one of the following modes:

  • Stand-alone. In this mode, Unicenter SOLVE:Operations uses a VSAM data set, known as the UAMS data set, to hold all user-related information, including passwords.

  • Partial Security Exit. In this mode, the UAMS data set is still used. It contains user-related information. However, an exit is used to interface to an external security system (that is, RACF, eTrust CA-ACF2 Security, or eTrust CA-Top Secret Security) for user and password validation.

  • Full Security Exit. In this mode, no UAMS data set is used. The security exit provides all information about users, including what SOLVE facilities can be used, and so on.

What are the pros and cons of each mode?

  • (Pro) The stand-alone mode allows quick installation and initial testing of the product(s). No external involvement is required.

  • (Con) Stand-alone mode has no synchronization of user IDs or passwords with any external security system.

  • (Pro) The partial security exit approach synchronizes the user ID and password information with the external security system. This allows the security managers to oversee access to SOLVE.

  • (Con) A partial security exit must be used. One may need to be written, although source samples and two out-of-the-box exits are supplied with the product.

  • (Pro) A full security exit allows all SOLVE user security and profile information to be managed by the external security system. There is no UAMS data set.

  • (Con) A full security exit is complicated. It must perform a significant amount of additional processing. Most external security systems are not set up to store the extra information that SOLVE requires. Various workarounds are possible, but none are simple.

The recommended security approach for SOLVE products is the partial security exit, in conjunction with a UAMS data set. Specifically, we recommend the NMSAF security exit solution.

Note: You can share the UAMS data set across SOLVE regions. This includes across LPARs. SOLVE will preserve data set integrity during updates.

The security exit interface in Unicenter SOLVE:Operations is fully documented. In addition, the product comes with sample exits (in source form) that can be used as a starting point for writing your own exit. While this is fine for those installations that have the time and expertise to write and maintain an exit, what about other installations that just want to use the product, but with an external security system?

To this end, we supply the following supported exits that can be used with Unicenter SOLVE:Operations:

  • 'PARTSAF' is an exit that implements basic SAF security. This supported exit has basically the same functionality as the supplied SAF sample exit. Being a SAF-based exit, it will work with the three main security systems (CA's eTrust CA-ACF2 and eTrust CA-Top-Secret, and IBM's RACF).

  • 'NMSAF' is an exit that provides a comprehensive security solution. Also SAF-based, it too can work with all the main security systems. As described later, this exit has significant capabilities and can be used to replace most in-house written security exits.

You can control the type of security that a Unicenter SOLVE:Operations region will use with the SEC JCL parameter, which is typically specified in the RUNSYSIN PDS member in the execution JCL for the Unicenter SOLVE:Operations region. The following values can be specified:

SEC=NO No security exit. UAMS-based security only.
SEC=PARTSAF Use the supplied basic SAF security exit.
SEC=NMSAF Use the supplied advanced SAF security exit
SEC= lmname Use an installation-supplied security exit where the name of the load module is lmname. (See the documentation for details on how the exit informs Unicenter SOLVE:Operations that it is a partial or full exit).

NMSAF Security Exit Solution

As mentioned earlier, we recommend use of the NMSAF partial security exit. Use of this exit means that the UAMS data set is still required. However, we believe that the split between what is stored in the UAMS data set and what is maintained in the external security system is a sensible one.

The design philosophy of the NMSAF security solution is based on the following assumptions:

  • An understanding that most installations have a centralised security administration function

  • The approach that many sites took when implementing a full security exit

  • The use of SOLVE Modelling and Group User IDs

  • A trade-off between the need to have and administer the UAMS data set as opposed to the inflexibility and maintenance problems associated with a full security exit

The main reason why it was decided to not to implement the NMSAF solution using the full security exit approach was because the external security systems are not set up to easily (if at all) store additional user data. Not everything that Unicenter SOLVE:Operations needs to know about a user maps to simple access levels. As an example, one field in the UAMS database record for a user is the initial OCS command, which is a character string that is treated as a command when the OCS facility is started. And this is just one of many examples.

The NMSAF solution uses the external security system and the UAMS database in the following ways:

  1. At system initialisation, the NMSAF exit reads a configuration file and builds a list of resource names. Each resource name is associated with a model user ID name. (A model user ID is a UAMS record).

  2. When a user logs on, and the user ID has not been seen before (that is, there is no UAMS record), the user is tested against the list of resource names. The first resource that the user has (at least read) access to is used to determine the name of the model user ID record that this user will be modelled on.

  3. A new user ID record is created in the UAMS data set using this chosen model. The user is then allowed to log on, and will be presented with a screen where some other details can be provided.

To make administration easier, we recommend that you distribute the system with a set of model user ID records that in turn are members of a group. In Unicenter SOLVE:Operations, a user ID record that is a member of a group takes all the important information from the group record at logon time. The basic user ID record only has personal information (and the group name). Thus, it is very simple to alter the privileges for all members of a group by merely altering the group definition.

Of course, password maintenance, and so on, is completely managed by the external security system. (You can allow a Unicenter SOLVE user to change their external security system password using a Unicenter SOLVE:Operations panel, or you can prevent this, requiring them to change the password through some other means).

If users are not defined on the external security system, or suspended or revoked, they will not be able to log on to the Unicenter SOLVE:Operations region.

At this time, the only ongoing UAMS maintenance that is required is the occasional cleanup of old user IDs (that is, users that have been deleted from the external security system).

If you need to change the authority of a user, you can simply delete the UAMS record. The next time they log on, the latest resource access levels will be used to choose a new model (and thus group) for the user.

Of course, for users with special privileges, you can use the standard UAMS definition facilities to add the appropriate profiles. The external security system is still used to maintain the password (and prevent login if the user is suspended or revoked).

Some Useful NMSAF Tailoring Parameters

As mentioned earlier, the NMSAF solution uses a configuration file. This allows you to alter processing to suit your installation's requirements. These parameters are fully documented in the manual (see the reference at the end of this article). However, some of the useful parameters are mentioned here:

SYSCHECK { NO | YES } Controls whether system user IDs (the background users that a Unicenter SOLVE region uses for internal processing) will be validated with the external security system. The default is YES. Note, however, that even if the external security system inhibits the logon (for example, user not known), SOLVE still allows the logon (otherwise the system would not start).

APPCCHECK { NO | YES } Controls whether APPC logon requests will be validated by the external security system. Previously, it was recommended that this parameter be set to YES, especially because the WebCenter used APPC logon requests for web sessions. However, this caused problems with APPC sessions between Unicenter SOLVE:Operations regions by background (system) users. See later for more information.

MODELGROUP { resourcename | * modeluserid } These statements define the list of resource names to check the new user against, and the associated model user ID. To avoid having to permit everyone acesss to Unicenter SOLVE:Operations (for example, when everyone in an installation is allowed to use Unicenter SOLVE:Access Session Management), you can define a final entry in the list with an asterisk (*) instead of the resource name. If no previous resources could be accessed, and this list entry is reached, the user is automatically allowed to logon using the associated model user ID definition (which, along with its group definition, should have minimal privileges).

Security and the WebCenter Interface

We have changed the WebCenter interface security interface. Now, you can specify to external security systems (including NMSAF) that a logon request is from a WebCenter user rather than APPC. To enable this:

  1. Ensure that the JCL parameter XOPT=SXWEBU is specified in the SOLVE startup JCL (or RUNSYSIN file).

  2. Ensure that the security exit can handle a LOGON request with a subcode of 36 and a VALIDATE request with a subcode of 16. (NMSAF can handle these). Note that the current security exit interface documentation does not cover these codes.

Summary

Security is a very important part of any installation. Unicenter SOLVE:Operations provides a sophisticated and comprehensive security regime. The NMSAF solution is one way to easily exploit these facilities.

Manual Reference

The NMSAF security solution is fully described in the Unicenter NetMaster, NetSpy, and SOLVE Security Guide. Chapter 2 describes the solution, and Appendix A covers the parameter file that is used to control processing. This manual covers many other aspects of security, including details on how to write your own security exit.