About Client Authentication

The client authentication feature enables basic application server security by requiring that any client connecting to the SIMULIA Execution Engine supply credentials (e.g., user name and password).

The credentials are verified against a security domain defined by the SIMULIA Execution Engine administrator. If the credentials pass the security check, the log on is allowed; otherwise, it is rejected. A client that passes this security check is said to be “authenticated,” meaning that the identity of the client has been established.

A client is any program running on any computer in the network that attempts to contact the SIMULIA Execution Engine. SIMULIA Execution Engine clients include the Isight Design Gateway, SIMULIA Execution Engine stations, the SIMULIA Execution Engine Dashboard or WebDashboard, the SIMULIA Execution Engine command-line client, etc. Each of these applications must provide valid user credentials to connect to the SIMULIA Execution Engine and perform any related operations.

Once a client has provided valid credentials and is authenticated, those credentials can be used to determine access to specific resources and information. All other SIMULIA Execution Engine security features are built upon the authenticated credentials, so enabling this feature is a prerequisite to all other SIMULIA Execution Engine security features.

To enable this feature, the administrator configures the application server using the application server supplied tools. The application server is configured to authenticate all incoming connection requests against a particular security back-end infrastructure; usually LDAP is used, but most application servers support many other security protocols. This section describes how to perform this task for the LDAP security system, but your application server documentation should be reviewed for information on all possible options and configurations.

The instructions provided in this section assume the use of an LDAP server for authentication—specifically, Microsoft Active Directory. Other LDAP servers would be configured in a similar manner. WebSphere can also be configured to authenticate with the local computer. In this case, only users that have been added as a local user on the server system will be able to log on to the SIMULIA Execution Engine. This setup may be adequate for small test environments, but it is not suitable for production deployments. Some familiarity with LDAP is helpful to properly configure WebSphere to use LDAP.