[z/OS]

Authenticating with SAF on IBM HTTP Server (z/OS systems)

You can authenticate to the IBM® HTTP Server on z/OS® using HTTP basic authentication or client certificates with the System Authorization Facility (SAF) security product. Use SAF authentication for verification of user IDs and passwords or certificates.

Before you begin

The mod_authz_default and mod_auth_basic directives provide basic authentication and authorization support which is needed in mod_authnz_saf configurations. In addition, the mod_ibm_ssl directive provides support for SSL client certificates. If you use SAF authentication, ensure that the first three LoadModule directives from the following example are activated. If you use SSL client certificates, ensure that the mod_ibm_ssl.so LoadModule directive is activated as well.
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authnz_saf_module modules/mod_authnz_saf.so
LoadModule authz_default_module modules/mod_authz_default.so
# Uncomment mod_ibm_ssl if any type of SSL support is required, 
# such as client certificate authentication
#LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
If the mod_authz_default module is not loaded by your Web server, the server returns a response code 500 instead of 401 if the user is not authorized.

About this task

SAF authentication is provided by the mod_authnz_saf module. The mod_authnz_saf module allows the use of HTTP basic authentication or client certificates to restrict access by looking up users, groups, and SSL client certificates in SAF. This module also allows you to switch the thread from the server ID to another ID prior to responding to the request by using the SAFRunAS directive. For additional information, see the information center topic about SAF directives. Also, see the topic about migrating and installing IBM HTTP Server on z/OS systems for information about migrating your SAF directives.

Procedure

  1. If you are using SAFRunAs, permit the IBM HTTP Server userid READ access to the BPX.SERVER FACILITY class profile in RACF, and provide the target userid with an OMVS segment.
  2. If the APPL class is active in the security product (SAF), users who authenticate via this module must be permitted to the OMVSAPPL application ID.
  3. Determine the directory location you want to limit access to. For example: <Location "/admin-bin">.
  4. Add directives in the httpd.conf file to the directory or location to be protected with values specific to your environment.
    If you want to restrict access to files under the /secure directory to only users who provide a valid SAF user ID and password, consider this example.
    <Directory  /secure> 	
    		AuthName protectedrealm_title	
    		AuthType Basic   
    		AuthBasicProvider saf   
    		Require valid-user   
    </Directory>
    You can also restrict access based on user ID or SAF group membership by replacing the Require directive in the previous example, as follows:
    require saf-user USERID
    require saf-group GROUPNAME
    Avoid trouble: The SAF group must have a group identification number (GID) defined in the OMVS segment to restrict access based on SAF group membership. Use the following Time Sharing Option (TSO) command to determine whether an OMVS GID is defined for a SAF group.

    LISTGRP NOGIDGRP OMVS NORACF

  5. Optional: Specify Require saf-user or Require saf-group to restrict access to a specific SAF user or group.