The term “security context” refers to the operating system level security information about a particular user (e.g., it is the operating system’s identification of a particular user and the user’s associated permissions to system resources such as files, network resources, etc.). When any program is started, the operating system associates the program (process) with the security context of a particular user (usually the user that started it). The process has access only to the resources that the user is authorized for at the operating system level. For example, the process would only be able to access files for which the user had appropriate file permissions. When the Run-As feature is not active, all work is performed in a single operating system process, meaning that SIMULIA Execution Engine jobs could, in theory, access system resources (such as files) on behalf of a user when that user did not have permission to access the file. Through the SIMULIA Execution Engine infrastructure, users could retrieve a file from the SIMULIA Execution Engine station for which they would not typically have permission. In an extreme case it would be possible to write an Isight component (such as the Script component) to access other user’s in-progress work on the SIMULIA Execution Engine station where the component executes. This situation can be partially mitigated by running stations with restricted user names that have a minimal set of file access permissions. The SIMULIA Execution Engine Run-As feature prevents jobs from accessing any resource to which the original job submitter does not have valid operating system level permissions. In particular, the job cannot access files for which the submitter’s own user ID does not have permissions, including other users’ in-progress work on the same station. From an operating system point of view, the work is run in a process that is started with the job submitter’s security context and, therefore, has only that user’s resource permissions. When the Run-As feature is enabled, SIMULIA Execution Engine stations examine each incoming work item request. The work item contains the job submitter’s credentials in encrypted form (encryption techniques are described in About User Credential Encryption). The job submitter’s credentials are authenticated against the security domain (realm) configured by the system administrator. If the job submitter’s credentials do not authenticate, the work request is rejected. When the job submitter’s credentials are authenticated, a new process is started using those credentials. This secondary process is known as a “substation,” and it will perform the requested work on behalf of the job. The substation process performs the work required for the job including any access to system resources (such as files). If the job attempts to access files for which the submitter does not have proper operating system permissions, the file access is denied by the operating system. All temporary files created by the SIMULIA Execution Engine as part of running the job will be protected. Only the job submitter has read or write access to the work-in-progress files. Thus, different users’ jobs will not be able to access the files of other users on the same station. Substation processes are started for each distinct user on an as-needed basis in each SIMULIA Execution Engine station system in the network. The substation process continues to exist (suspended) after it completes a work assignment. If another piece of work for that same user arrives at that SIMULIA Execution Engine station, the already running substation process is awakened and reused. If a substation process remains inactive for a period of time, it will be terminated automatically. Inactive substations may also be terminated when a threshold on the number of processes is reached. When the main SIMULIA Execution Engine station shuts down, all substation processes that it started are also shutdown. | |||||||