As described in the topic Deployment Listeners, COBOL Server (beginning with version 5.0) provides optional features to prevent unauthorized users from deploying Web Services and COBOL EJBs.
If your Enterprise Server is enabled for security, you can configure your deployment listener or listeners to require user authentication. This ensures only known users can deploy services. User authentication is configured in the [security] section of the configuration text for the listener using the restricted and authentication settings. More information can be found under Deployment Listeners and The Web Conversation Type.
If your Enterprise Server security configuration includes an External Security Manager that supports resource access controls, such as LDAP-based security using the MLDAP ESM Module, you can additionally restrict which users can deploy services or retrieve deployed artifacts and deployment logs. This provides finer-grained control over deployment. It is enabled by creating an additional resource class (if it does not already exist) and adding rules to that class.
Resource access controls for service deployment are defined in the Enterprise Server Web resource class. (A different class name can be configured in the listener configuration.) The virtual directory from the request is matched against the names of the rules found in this class. The rule names can include wildcards, but usually they will match the virtual directories listed in the Web listener configuration, such as uploads. See the topic Deployment Services and Listeners for more information about virtual directories.
With LDAP-based security, you can use an LDAP administration tool or an LDIF file to add a container named CN=Enterprise Server Web under the resource container in your LDAP repository. By default, that container is named CN=Enterprise Server Resources.
Within the resource class, create rules for the virtual directories you wish to restrict. With the default Enterprise Server configuration, you would typically create rules named cgi and uploads. The "cgi" rule controls access to the mfdeploy program which accepts deployment requests, so only users who are granted access will be able to deploy. The "uploads" rule controls access to the actual deployment area, so it can restrict who can download deployed artifacts (such as service programs) or view deployment logs.
If you are using LDAP-based security, you would create these rules as LDAP objects of type microfocus-MFDS-Resource, with the names CN=cgi and CN=uploads. The attributes microfocus-MFDS-Resource-Class and microfocus-MFDS-UID are mandatory and must be set to some value, but they are not actually used by Enterprise Server and you can supply any value for them.
To grant or deny permissions to users and groups, use the deployment resources by adding Access Control Entries (ACEs) to the microfocus-MFDS-Resource-ACE multi-valued attribute of the appropriate rule.
For both the "cgi" and "uploads" rules, you should add a default ACE to control access for users who are not covered by more-specific ACEs. Normally, this would be deny:*:all, which blocks access by default. Alternatively, you can allow access by default using allow:*:all, in which case only users who are specifically blocked with deny ACEs would be prevented from deploying.
After the default ACE, you would add one or more ACEs to grant access to specific users or groups. For the "cgi" rule, to permit deploying services, a user must have both the "execute" permission (to run the mfdeploy.exe program) and the "add" permission (to perform an HTTP POST operation). So, for example, you might add an ACE like allow:SYSADM group:execute,add to the "cgi" rule to grant members of the SYSADM group permission to invoke the deployment service and upload a deployment package.
For the "uploads" group, authorized users need the "read" permission. This enables them to retrieve deployment logs, browse the deployment area, and download files from it (though that's not normally done, except for the deployment logs). A typical ACE for "uploads" is allow:SYSADM group:read.
Changes to these security settings normally take effect immediately. If ESF caching is enabled, there may be some delay until any cached security results expire.