DCAS Security

Enterprise Server provides a feature known as Digital Certificate Authentication Service (DCAS), that provides temporary credentials for users to sign on to an enterprise server region that is secured using the External Security Facility (ESF). The DCAS feature is most commonly used to provide single sign-on for TN3270 users using the Express Logon Facility (ELF), also known as Certificate Express Logon (CEL), or using an external single-sign-on provider such as Micro Focus Host Access for Cloud (formerly Host Access Management and Security Server) and its Automated Sign-On for Mainframe feature. The DCAS feature is not enabled by default.

In previous releases of Enterprise Server, enabling the DCAS feature created a security vulnerability, because access to the DCAS mechanism was not sufficiently restricted. A knowledgeable attacker could use DCAS to impersonate other Enterprise Server users. To correct this issue, a number of security features have been added to DCAS. This topic provides an overview of those features.

Internal and external DCAS

You can implement DCAS to work either internally with one or more TN3270 listeners and the Express Logon Facility, or externally to support advanced authentication systems such as Automated Sign-On for Mainframe. Here "internally" means the TN3270 listener calls DCAS directly, and it is not necessary to configure a DCAS listener. "Externally" means the DCAS listener connects to an external client such as Host Access for Cloud.

With internal DCAS, only TN3270 listeners can use DCAS. This makes it less vulnerable to attack. However, you can only use internal DCAS to implement Express Logon Facility, and not for any other purpose.

Internal DCAS is enabled in the configuration of each TN3270 listener that is to support Express Logon Facility. See the configuration options for the TN3270 conversation type for more information.

You can use external DCAS for Express Logon Facility and other DCAS applications. External DCAS is enabled by creating a custom listener with the DCAS conversation type. You might also need to configure your TN3270 listener to use external DCAS. See the topics Configuring a region for Express Logon Facility and Configuring a region for Automated Sign-On for Mainframe.

DCAS client authentication

A DCAS listener must use TLS (SSL). With TLS you can optionally require client authentication, which prevents clients from connecting to the listener unless they have a client certificate that is signed by a certificate authority (CA) known to the listener. Enabling client authentication is an additional security measure you can use to prevent abuse of the DCAS feature. See the topic SSL Options for more information.

When client authentication is enabled for the DCAS listener, by default, the listener also requires that the client certificate be associated with an Enterprise Server user, using the certificate registration information. This is also known as "certificate mapping". See the topic User Certificate Registration for CICS Web Interface Servers and DCAS. This requirement can be relaxed using the DCAS configuration setting allow unauthenticated clients=yes; refer to the list of configuration settings for the DCAS conversation type for more information.

When using client certificates with DCAS (or other listeners), the enterprise server region administrator might also need to add the following setting to the listener configuration:

[MF SSL]
match client hostname=no

This tells the listener that client certificates do not need to identify the client host machine, but may identify a user.

Restricting certificate mapping

There are two types of DCAS requests, referred to as "Format 1" and "Format 2" in the IBM and Micro Focus documentation. Format 1, usually used by Express Logon Facility, accepts a user's certificate and returns an Enterprise Server user ID and passticket. Format 2, typically used by external authentication systems such as Automated Sign-On for Mainframe, accepts a user ID and returns a passticket. You can configure which formats are accepted by a DCAS listener. See allowed formats under DCAS conversation type for more information.

For a Format 1 request, the DCAS listener must "map" the certificate to an Enterprise Server user, as it does for the client certificate when client authentication is enabled, as described in the previous section. It does this by consulting the collection of registered certificates. If the certificate is not found, the request is rejected.

Note: Do not confuse the client certificate, which is optionally sent by the client as part of establishing the TLS conversation, with the user's certificate that is contained in the Format 1 request. The client certificate identifies the client program; the user certificate identifies the user who is requesting a passticket to sign on to the enterprise server region. The two might be the same certificate, or not, but they are used for different purposes. Also, the client certificate is optional, but the user certificate must be supplied as part of the Format 1 request.

After the certificate is mapped, the DCAS listener checks to see if the mapping is allowed for DCAS. By default, registered certificate mappings can be used for both DCAS and CICS Web Interface (CWI). An administrator can mark a mapping as not allowed for DCAS by adding the line dcas=no to the certificate mapping file. This can also be done when a certificate is registered using the cascertreg utility. See the topics User Certificate Registration for CICS Web Interface Servers and DCAS and cascertreg for more information.

This additional control lets an administrator specify that a mapping can only be used for a specific purpose (currently DCAS or CWI), or disable a mapping for all purposes while retaining it for future reference.

Note: The mapping restrictions and other data in the certificate registration file is read the first time a user certificate is received by DCAS or CWI after region startup. Changing the settings in the file after that will not take effect until the region is restarted.

DCAS supports an option to do an implicit client mapping, for Format 1 requests only, from the Common Name (CN) component of the client certificate's Subject Distinguished Name. If this is enabled by setting userid source=cnv or userid source=cn fallback in the listener configuration, then a certificate registration is not required if the client certificate has a CN which is a valid Enterprise Server user ID, or can be mapped to an Enterprise Server user ID by the External Security Facility, if map CN=yes is also configured.

DCAS user authorization

The DCAS listener has two optional authorization checks that can also be enabled to restrict the users for whom DCAS generates passtickets. These checks are made using the external security (ESF) configuration of the enterprise server region.

By default, after identifying the user for whom a passticket is being requested, and validating that user ID, DCAS queries external security to see if that user has "update" access to a resource in the PTKTDATA class. The name of the resource is the APPLID supplied in the request. When DCAS is invoked for Express Login Facility, the APPLID is supplied by the TN3270 client, but could be modified by the TN3270 listener. See the configuration options for the TN3270 conversation type. For other DCAS uses, the APPLID is supplied by the DCAS client. By convention it is typically the enterprise server region name.

The purpose of the PTKTDATA resource class is similar to how it is used on the mainframe, but details of its use are different.

If the PTKTDATA resource class is not defined, this check passes for all requests. The check can also be disabled in the listener configuration using the check user authorization setting; this could be useful for both development and test enterprise server regions.

DCAS can also be configured to make an authorization check using the client certificate. This check is disabled by default and must be enabled using the check client authorization configuration setting. When it is enabled, if the client sends a certificate, DCAS extracts the subject (an X.509 distinguished name) and request access to a resource with that name in the DCASCCRT class. For a Format 1 request, "read" access to this resource is required; for a Format 2 request, "control" access is required.

Note: Clients can be forced to send a certificate by configuring the DCAS listener appropriately.

The certificate subject is a distinguished name with components ordered from least-specific to most-specific and separated by slashes, for example /C=US/ST=MD/L=Rockville/O=Micro Focus/OU=Development/CN=Some User. Depending on how you issue user certificates, you might use this to restrict DCAS passtickets to users in particular groups. For example, consider these security rules:

Resource name	Access control list
`/OU=Customer Agent/`	`allow:*:control`
`/OU=Administrators/`	`allow:*:read`
`**`	`allow:*:none`

With these rules:

User certificates for users in the "Customer Agent" organizational unit can be used for Automated Sign-On for Mainframe and for Express Login Facility.
User certificates for users in the "Administrators" organizational unit can be used for Express Login Facility, but not for DCAS Format 2 requests. This makes it more difficult for an attacker to impersonate an administrator, while still giving administrators a single sign-on mechanism for TN3270.
User certificates for users in other organizational units cannot use DCAS at all.

Other DCAS security controls

The following additional security measures can also be used to help prevent abuse of the DCAS feature. These are available even in older versions of Enterprise Server that lack the new features described above.

Restricting access to passtokens (LDAP-based security): When an enterprise server region uses LDAP-based security, access to the passtoken feature can be restricted on a per-user basis using attributes of the LDAP user objects. This can be used to prevent certain high-risk users, such as system administrators, from being signed on to a centerprise server region using DCAS.
Listener binding: A DCAS listener can be configured to bind to only a particular network interface (specified as a hostname or IP address), rather than to "*", which means all interfaces. This is most commonly used with localhost to bind the DCAS listener only to the loopback interface, preventing connections to it from other systems on the network.
Listener conversation filtering: The Micro Focus Communications Server has a simple firewall mechanism known as conversation filtering. It can be used to restrict which systems can connect to a DCAS listener. See the topic Conversation Filtering for more information.