Enhanced security for HTTP and MFBINP

Beginning with release 9.0, Enterprise Server offers options for enhanced security for HTTP and MFBINP conversations. These options are supported by the Web Services and J2EE conversation type, and some of the HTTP-related options apply to the Remote File Access (RFA) and Web conversation types.

Note: RFA has a number of security options specific to it.

Enhanced security works in conjunction with other Enterprise Server features, such as external security and conversation filtering (firewall), to improve the overall security posture of the enterprise server instance and provide defense in depth.

Enhanced security is configured in the listener Custom Configuration filed.

Enhanced security includes the following features, most of which can be used independently.

Authentication

Authentication verifies the identity of the client connecting to the enterprise server listener. Typically, it is the end user who is authenticated, but in some cases an organization might authenticate the client system using SSL/TLS and a client certificate.

With enhanced security, if authentication is enabled, it can be required — all clients must authenticate successfully or the conversation is terminated — or it can be optional. Optional authentication lets a client authenticate, in which case it may be granted additional access that is not available to an unauthenticated client.

Authentication requires that Enterprise Server External Security is configured for the enterprise server region.

Authentication options apply to RFA as well as Web Services and J2EE.

Authorization

Authorization restricts what requests a client is allowed to make. If authorization is enabled, then a security access check is performed using either the authenticated user, or a default user account if authentication is optional and the client is not authenticated.

The parameters of the access check depend on the protocol (HTTP or MFBINP), the type of request, and the resource, such as the HTTP URL, named in the request.

By default, access requests are made against the resource class "Communications Server Service Control". The name of the class can be changed in the listener configuration.

Authorization requirements for HTTP requests

For HTTP, the path portion of the URL in the request is the resource name used for the access request.

The HTTP method determines the required permission level:

  • HTTP GET, HEAD, and OPTIONS require read permission.
  • POST requires update permission.
  • PUT requires add permission.
  • DELETE requires delete permission.
  • Any other request method requires control permission.

For example, a web service client making a POST request to a Web service with the following URL:

https://eshost:9000/tempuri/account_update/credit?account=12345&amount=500.00
This would require update permission for the resource /tempurl/account_update/credit in the resource class "Communications Server Service Control".

Authorization requirements for MFBINP requests

MFBINP requests always ask for execution permission. The resource name for MFBINP access requests is the service name for normal service requests, and BINP control message for other types of MFBINP messages such as transaction control.

COBOL programs deployed to Enterprise Server as EJBs have their service names specified as part of interface mapping, and the service names will also be visible in the service objects configured in ESCWA for an enterprise server region. Built-in services used by functions such as casfile and casout include the following:

CASA_Sub_JCL
Submit JCL
CASA_File_Set
casfile operations (set CICS files)
CASA_Out_JCL
casout JCL spool / catalog functions
CASA_Out_Set
casout other functions

With COBOL Application Server (CAS) service names, you might need to experiment and consult the logs to see precisely which service is being allowed or denied for a given task.

Constraints

Constraints restrict which features of the Web Services and J2EE conversation type a given listener supports. They are useful to disable features you never use, in order to reduce the attack surface, or to create specific listeners for different purposes, which might be bound to different interfaces, use different firewall rules, or have different authentication and authorization settings.

With constraints you can disable any number of the following features:

HTTP requests
Disabling this will also disable ESMAC
MFBINP requests
Disabling this will also disable CAS services, dynamic debugging, and MFBINP file handler.
ESMAC
Including the ESMAC service used by ESCWA.
All CAS services
Such as, cassub and casfile.
Dynamic debugging
MFBINP file handler
Used for remote access by the Data File Editor.

Configuration

All of these security options are set in the [Security] section of the Custom Configuration filed for the listener.

Note: All setting names and values are case-insensitive.

Syntax

[Security]
authenticate=required|enabled|optional|ignore failure|disabled
default user=username
authorize=required|disabled
restricted=yes|http|mfbinp|no
authentication=types
realm=string
keep authentication when passive=yes|no
allow HTTP=yes|no
allow MFBINP=yes|no
allow ESMAC=yes|no
allow CAS services=yes|no
allow MFBINP FH=yes|no
allow dynamic debugging=yes|no
authenticate
The possible settings are:
required
All clients must authenticate.
enabled
Authentication is permitted; clients which do not authenticate will use the default user account.
optional
Synonym for enabled.
ignore failure
Like enabled, but if authentication is supplied by the client but fails, treat the request as if authentication was not attempted (use the default user).
disabled
Do not perform authentication.

The default value is disabled unless restricted (see below) is enabled for the protocol, in which case the default is enabled.

This setting applies to RFA and Web listeners as well.

Note: Do not confuse this setting with authentication, described below.
default user=string
Set string to the name of the default user account, used if authentication is optional and the client does not authenticate. The default value is MFCSUSER.
authorize
Controls whether authorization is performed for the request. Possible values are required and disabled.

The default is disabled.

restricted
For Web Services and J2EE listeners, this setting can be used to restrict authentication to only one of the two protocols (HTTP and MFBINP). For historical reasons, it can also be used with listeners using the Web conversation type, with some differences. Possible values are:
yes

The authenticate setting applies to all requests (HTTP and J2EE). This is the default if authenticate is set to anything other than disabled.

HTTP
The authenticate setting applies only to HTTP requests. (For RFA and Web, this means all requests, as they do not use MFBINP.)
MFBINP
The authenticate setting applies only to MFBINP requests.
no
This setting is only useful for the Web conversation type, where it means authentication is allowed but not required.
While this setting can be used with RFA, it does nothing useful for that conversation type, since if authentication is enabled the only useful value for restricted is yes (or HTTP, which has the same effect).
authentication=types
Set the types of authentication that are supported by this listener. This setting applies to RFA and Web listeners (HTTP authentication mechanisms only) as well.

The value of this setting is one or more of the following tokens, separated by spaces and/or commas:

HTTP
Allow HTTP Basic Authentication. This passes credentials in Base64 encoding, so if you are concerned about sensitive data on the network, you should enable SSL/TLS.
MFBINP
Allow authenticating using the MFBINP Security header. This passes credentials in the clear on the network (unless SSL/TLS is used).
MF
Support an older proprietary HTTP authentication mechanism, which was used by older product releases for COBOL service deployment. This passes credentials in the clear on the network (unless SSL/TLS is used).
certificate or cert
Allow clients to authenticate using client certificates. This requires an SSL/TLS listener and certificate registration. This uses the same certificate registry as the CICS Web Interface and DCAS features. See User Certificate Registration for CICS Web Interface Servers and DCAS for more information.
Note: The Web Services and J2EE conversation type supports this authentication mechanism for both HTTP and MFBINP.
register

Like certificate, but if the client sends an unrecognized certificate, try the other enabled authentication mechanisms (for example HTTP). If the client is authenticated using one of them, register the client's certificate under that identity for future use.

The default value is HTTP, MFBINP, MF.
Note: Do not confuse this setting with authenticate, discussed above.
realm=string
For HTTP Basic Authentication, this sets the realm string. Browsers display the realm when prompting for credentials for Basic Authentication, and use the realm to determine whether they can send cached credentials. This setting is also supported by RFA and Web.

The default value is "MF Communications Server for region region-name".

keep authentication when passive
Set this to yes to have MFBINP sessions retain their authentication status if they are passivated. Passivation allows an MFBINP session to be preserved across conversations, in the same MFCS instance. This feature is rarely used by MFBINP clients.

If this is not enabled, clients trying to reactivate an MFBINP session will have to re-authenticate. This is more secure if an attacker attempts to get the session ID of a passivated session. For example, because the client stored it in a file.

The default value is no.

allow feature
These constraint settings can be used to disable various features in a Web Services and J2EE listener. Set the value to yes to enable the feature or no to disable it.

The default value is yes for all features.