Previous Topic Next topic Print topic


Service Deployment and Security

Server Enterprise Edition provides a deployment feature to let developers package COBOL programs as Web Services or EJBs and deploy them to an Enterprise Server instance. The deployment process uploads the packaged service (in the form of a COBOL Archive or "CAR" file) to ES, then invokes an installer (mfdepinst) that extracts the contents from the archive, creates package and service objects in the Micro Focus Directory Server repository, and notifies ES of the new service.

Service deployment is initiated by a deployment client, running under the control of a developer or administrator.

Deployment and Security

Creating service and package objects in the MFDS repository requires update access, which may not be granted to all users. mfdepinst has to present credentials (a username and a password) to MFDS when it tries to create those objects. In a secured installation, deployment requests from users may fail to create service and package objects because of insufficient permissions.

The default configuration installed with Server Enterprise Edition lets mfdepinst create objects in the MFDS repository, but when security options are changed it's easy to cause deployment requests to fail. (This is actually the appropriate behavior; when an installation is secured, it should prevent unauthorized access.) This is particularly true when external security is enabled.

How Deployment Credentials are Verified and Authorized

In early releases of Server Enterprise Edition, the credentials sent to MFDS by mfdepinst were verified against entries in the file cciusers.dat. In more recent releases, MFDS keeps its own database of user information as part of the repository.

External security, which is enabled by specifying an external security manager (ESM) for MFDS security, lets MFDS use an outside facility, such as an LDAP server, to verify user credentials.

How MFDS is configured determines how the username and password sent by mfdepinst will be verified, and what determines their level of access. If you are using internal security, you'll have to ensure that the username and password sent by mfdepinst are configured in MFDS, and that the user account used by mfdepinst has "add" access for the MFDS repository. Similarly, if you're using external security, your ESM will have to accept the username and password sent by mfdepinst and grant it access to add objects to MFDS.

The ES Administration Guide discusses these topics in more detail.

Previous Topic Next topic Print topic