check client authorization=client-authorization-option
| client-authorization-option | If this is set to "yes" or "1", client authorization for DCAS is checked. |
| Default: | no |
| Values: | No, 0, Yes, 1 |
Suppose you have a region that will use DCAS with TN3270 ELF for one set of users, and you also have another specialized application which uses DCAS Format 2 requests to sign on any of a small group of special users. The ELF users are all issued personal certificates with Subject DNs that include O=My Company Inc (an Organization element) and OU=ELF Users (an Organizational Unit). So these users can be recognized by these elements in their client certificate subject names.
Meanwhile, anyone who has a company client certificate can use DCAS for the specialized application, but only to create passtickets for user IDs that are members of the SPECAPP user group.
You could enable the client authorization check and create the following rules in the DCASCCRT resource class:
| Rule name | Access control entry | Comment |
|---|---|---|
| **/O=My Company Inc/OU=ELF Users/** | allow:*:read | Anyone who connects to DCAS with a client certificate with a name matching this pattern can make a Format-1 request |
| **/O=My Company Inc/** | allow:SPECAPP group:control | Anyone with a client certificate issued by our company can create a passticket for a user ID in the SPECAPP group |
Creating rules for the DCASCCRT class may require some planning, but it allows fine-grained control over the parameters of permitted DCAS requests.
openssl x509 -in file.pem -noout -subject -nameopt compat
The cascertreg utility now also inserts a comment into certificate registration files with the subject in this format.
Comments:
This setting can be used to enable the optional client-authorization check that DCAS normally makes before requesting a passticket for the user. This feature requires the check user authorization setting also be enabled (this is the default).
The main function of the DCAS service is to ask the External Security Facility to create a passticket (temporary password) for a user. The DCAS user authorization check, which is enabled by default, queries the security system to see whether the user identified by the request is allowed to use passtickets. The client authorization check, which is enabled using this setting, checks whether the certificate sent by the client as part of its connection to the DCAS listener is allowed to use DCAS.
In other words, client authorization restricts who can make DCAS requests, while user authorization restricts for whom they can be made. The client authorization check is made in the name of the requested user, so it can also be used to restrict which users can be granted a passticket when a request is made by a particular client.
If this setting is enabled then before requesting the passticket, DCAS will make an ESF Authorization request using the request user ID. The resource name will be the Subject Distinguished Name from the client certificate and the resource class is DCASCCRT. The user must have Read access to this resource for a Format 1 (ELF) request, or Control access for a Format 2 (Automated Sign-on for Mainframe) request; otherwise the DCAS request is rejected. If this setting is enabled and the DCASCCRT resource class does not exist, all DCAS requests will be rejected.
The DCASCCRT resource class is not defined in the sample LDAP security definitions included with Enterprise Server. To make this authorization check useful you must define the DCASCCRT class and create suitable resource access rules in it.
For additional DCAS security, enable this option and configure the PTKTDATA resource class rules for your environment. See DCAS Security for more information.