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.
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.
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.
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 a Format 1 request, the DCAS listener must "map" the certificate to an Enterprise Server user, much 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.
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.
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.
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 usually 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 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.
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 your organization issues 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:
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.