The ClearPath Extension Kit for MCP utilizes the MCP environment, the Windows environment, and the Docker environment, all of which exist on the platform supporting the MCP. Each of these environments have unique security paradigms, and it is important to understand when the boundaries between these environments are crossed, and what security paradigms are in effect at each stage. A system administrator has significant flexibility in how far a system may be restricted or allowed to access useful functionality and the security implications that result from those decisions.
There are two granulated privileges that allow access to the components of the ClearPath Extension Kit for MCP in the MCP environment. In addition, access to the Windows and Docker environments requires authorization from the Windows host. The ClearPath Extension Kit for MCP utilizes Credentials Files and Authentication Support to supply credentials and authenticate users in the Windows environment. For a description of credentials, the MAKECREDENTIALS utility, and the credentials files, see NXSERVICES CREDENTIALS Files. For additional information about Authentication Support, see Authentication Support Features.
Associating an MCP user with a Windows User
The association between an MCP user and a Windows User is based on the NXSERVICES Credentials File that is used when an Extension Kit component is invoked in the Windows environment from the MCP. A credentials file is created using the MCP MAKECREDENTIALS utility containing the Windows username and password. Credentials files may be local to a usercode or global for use by multiple users. They are hashed for protection and are not easily deciphered to expose the password. Credentials files cannot be copied between usercodes. Usercoded credentials file must be created by running MAKECREDENTIALS under the usercode where it is created, and a global credentials file must be created by an unusercoded process, for example, running MAKECREDENTIALS from the ODT.
The Windows username and password are assigned in the Windows environment of the Extension Kit. Nothing in the MCP environment controls the security of the Windows environment with respect to the account associated with the MCP usercode, so care must be taken when defining the account in Windows.
The Windows user account may be configured to belong to various groups defined in the Windows environment. To simplify, Windows user administration for all MCP users who have been granted access to the ClearPath Extension Kit for MCP environment, a Windows user group named MCP_Users is typically used (see “Giving the MCP_Users group access to Docker” below).
When a Windows user account is created, it is a best practice, and strongly encouraged, that the Windows users not be Windows administrators. This will further protect the MCP firmware environment from encountering an unintended interruption of service should an MCP user attempt to do something dangerous like a platform reboot.
There are a number of ways to map an MCP user to a Windows user, depending on the usage of the Extension Kit. Best practices in a development environment might be different from those in a production environment. What is most important is understanding the implications of the various options as a result of the Credentials File used for authentication and Windows user account definition. Two scenarios for associating MCP Usercodes with Windows User Accounts are described in the following examples.
Example for One-to-One Mapping
This approach uses a unique Windows user for each unique MCP user, which has been granted PLATFORMACCESS. Assume there are three MCP users with usercodes: USER01, USER02, and USER03. Three MCP users would require three Windows users be created in the Windows MCP_Users group. A likely naming scheme for the Windows users might be MCPUser01, MCPUser02, and MCPUser03.
When MCPUser01 through MCPUser03 are created, the Windows usernames and passwords must be provided to each MCP user to whom they are issued, along with the computer name of the Windows platform, and this information will be used by each MCP user to create their NXSERVICES credentials file as documented in NXSERVICES CREDENTIALS Files.
Example for Many-to-One Mapping
An alternate method, is where multiple MCP users map to a single Windows user. The example of many-to-one mapping may be used where the Docker host environment is viewed as a shared resource of all MCP usercodes though access to a single, global credentials file. Platform access users therefore share the Docker environment and use the same credentials file. The credentials file password could be restricted so that platform access is secure from log on attempts outside of the EPM interface.
Although the images are built and run using the same Windows account, AUTOMAP maps to the usercode of the initiator, so each person running is restricted to the MCP files that the usercode can see. The Images are also tagged with the usercode to identify who created the image.
Giving the MCP_Users group access to Docker
In the Docker for Windows environment, Windows administrators have access to the Docker environment by default. Since the platform is considered an MCP platform, the MCP_Users group is added to Docker's daemon.json file. This allows all MCP_Users access to the Docker environment. The primary security controls to Docker's capabilities are applied by the MCP software, the MCP user security model, and the Windows user security model. Only all three allow MCP users to utilize the ClearPath Extension Kit for MCP environment.
