[z/OS]

Directives SAF

Ces paramètres de configuration contrôlent la fonction SAF (System Authorization Facility) pour IBM® HTTP Server. Utilisez les directives SAF pour accorder à IBM HTTP Server l'authentification d'utilisateur.

Directive AuthSAFAuthoritative

Dans les éditions précédentes, la directive AuthSAFAuthoritative permettait de définir si l'autorisation est transmise à des modules de niveau inférieur. En raison des modifications apportées à l'API d'Apache HTTP Server dans cette édition, la directive AuthSAFAuthoritative n'est plus requise ni acceptée.

Directive Description
Syntaxe AuthSAFAuthoritative on | off
Valeur par défaut on
Contexte répertoire, .htaccess
Module mod_authnz_saf
Valeurs on | off

Dans les éditions précédentes, la directive AuthSAFAuthoritative permettait de définir si l'autorisation est transmise à des modules de niveau inférieur. En raison des modifications apportées à l'API d'Apache HTTP Server dans cette édition, la directive AuthSAFAuthoritative n'est plus requise ni acceptée.

Si elle était utilisée dans une édition précédente, elle doit être retirée de la configuration.

Directive AuthSAFExpiration

La directive AuthSAFExpiration définit la valeur affichée dans l'invite du navigateur. Le serveur envoie la valeur spécifiée pour la directive AuthName et cette phrase courte dans un en-tête de la réponse HTTP, puis le navigateur les affiche pour l'utilisateur dans une fenêtre d'invite de mot de passe. L'expression courte est soumise aux mêmes limitations de caractères que la valeur spécifiée pour la directive AuthName. Par conséquent, pour afficher un caractère spécial dans la fenêtre d'invite de mot de passe, le serveur doit convertir le caractère spécial de la page de codes EBCDIC CharsetSourceEnc en page de codes ASCII CharsetDefault. Par exemple, si vous souhaitez afficher un 'a' minuscule avec un tréma et si le fichier httpd.conf contient la page de codes EBCDIC "CharsetSourceEnc IBM-1141" et la page de codes ASCII "CharsetDefault ISO08859-1" de la langue allemande, vous devez coder l'expression en utilisant la valeur '43' hexadécimale, qui effectue la conversion vers le caractère ASCII correct.

Directive Description
Syntaxe AuthSAFExpiration phrase_courte
Valeur par défaut désactivé
Contexte répertoire, .htaccess
Module mod_authnz_saf
Valeurs off ou phrase_courte

Si vous définissez une phrase pour la directive AuthSAFExpiration, IBM HTTP Server peut inviter l'utilisateur à mettre à jour son mot de passe SAF à son expiration. Lorsque l'utilisateur entre un ID valide et un mot de passe SAF mais que ce dernier a expiré, le serveur lui renvoie une réponse indiquant que l'authentification est requise avec une invite spéciale permettant à l'utilisateur de mettre à jour le mot de passe expiré. L'invite est constituée d'un domaine (la valeur de la directive AuthName), suivi de la valeur phrase_courte de la directive AuthSAFExpiration.

Par exemple, considérons la configuration suivante :
<Location /js>
AuthType basic
AuthName "zwasa051_SAF"
AuthBasicProvider saf
Require valid-user
Require saf-group SYS1 WASUSER
AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw"
</Location>

Si l'utilisateur essaie d'accéder à un fichier dont l'URL commence par /js, le serveur invite à entrer un ID et un mot de passe SAF. Le navigateur affiche une invite contenant le domaine. Le domaine correspond à la valeur contenue dans la directive AuthName, c'est-à-dire zwasa051_SAF dans cet exemple.

Lorsque l'utilisateur entre un ID et un mot de passe valide, si le mot de passe a expiré, le serveur relance l'invite, mais avec la valeur zwasa051_SAF EXPIRED! oldpw/newpw/newpw. Quelle que soit l'invite, l'utilisateur doit entrer à nouveau le mot de passe expiré, suivi d'une barre oblique, un nouveau mot de passe, une autre barre oblique et encore le nouveau mot de passe.

Si le mot de passe est mis à jour correctement, le serveur envoie une autre réponse indiquant authentification requise avec une invite spéciale différente. Cette dernière interaction est nécessaire pour forcer le navigateur à comprendre quel mot de passe il doit mettre en mémoire cache. L'invite cette fois est constituée du domaine suivi de l'invite Entrez à nouveau le mot de passe. Dans cet exemple, ce serait zwasa051_SAF Ré-entrer nouveau mot de passe.

Directive AuthSAFExpiredRedirect

La directive AuthSAFExpiredRedirect spécifie une URL vers laquelle une requête doit être redirigée si votre mot de passe est arrivé à expiration lorsque vous utilisez mod_authnz_saf pour l'authentification sous z/OS.

Il s'agit d'une alternative à l'utilisation d'AuthSAFExpiration.

Directive Description
Syntaxe AuthSAFExpiredRedirect url
Valeur par défaut désactivé
Contexte répertoire, .htaccess
Module mod_authnz_saf
Valeurs off ou url

Directive AuthSAFReEnter

La directive AuthSAFReEnter définit la valeur ajoutée au domaine après la modification d'un mot de passe. Pour plus d'informations concernant le codage des caractères spéciaux, consultez la directive BAuthSAFExpiration.

Directive Description
Syntaxe AuthSAFReEnter phrase_courte
Valeur par défaut Ré-entrer nouveau mot de passe
Contexte répertoire, .htaccess
Module mod_authnz_saf
Valeurs off ou phrase_courte

La définition explicite d'une phrase autre que "Réentrer nouveau mot de passe" pour la directive AuthSAFReEnter permet à l'administrateur d'afficher un autre message après la mise à jour d'un mot de passe expiré. Si la directive AuthSAFExpiration a pour valeur off, elle n'a aucun effet.

Par exemple, considérons la configuration suivante :
<Location /js>
AuthType basic
AuthName "zwasa051_SAF"
AuthBasicProvider saf
Require saf-user SYSADM USER152 BABAR
AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw"
AuthSAFReEnter "Entrez de nouveau le mot de passe"
</Location>

Dans cet exemple, une fois que le mot de passe expiré a été mis à jour, le serveur envoie une autre réponse indiquant que l'authentification est requise avec la valeur issue de la directive AuthSAFReEnter. Cette dernière interaction est nécessaire pour forcer le navigateur à comprendre quel mot de passe il doit mettre en mémoire cache. L'invite cette fois est constituée du domaine suivi d'une phrase spéciale. Dans cet exemple, ce serait zwasa051_SAF Ré-entrer nouveau mot de passe.

Directive SAFAPPLID

Remplace l'ID application (APPLID) transmis au sous-programme pthread_security_applid_np() de systèmes d'exploitation sous les configurations par "SAFRunAs".

Directive Description
Syntaxe SAFAPPLID application-id
Valeur par défaut Aucune (Certaines configurations de systèmes d'exploitation traitent implicitement l'ID comme "OMVSAPPL")
Contexte répertoire, .htaccess
Module mod_authnz_saf
Valeurs application-id

Lorsque la directive SAFRunAs est utilisée, sous certaines configurations de produit de sécurité où la classe "APPL" est active, le produit de sécurité vérifie que l'utilisateur authentifié a accès à la classe "OMVSAPPL". Si SAFAPPLID est configuré, l'ID application spécifié est utilisé à la place.

Directive SAFRunAs

La directive SAFRunAs définit l'ID utilisateur SAF sous lequel une demande sera servie.

Directive Description
Syntaxe valeur SAFRunAs
Valeur par défaut désactivé
Contexte répertoire, .htaccess
Module mod_authnz_saf
Valeurs off | %%CLIENT%% | %%CERTIF%% | %%CERTIF_REQ%% | %%CERTIF%% /prefix | surrogate-username /prefix | <surrogate ID>
  • Off : le serveur exécute la demande sous l'ID utilisateur du serveur Web.
  • %%CLIENT%% : le serveur exécute la demande sous l'ID proposé dans l'en-tête de la demande d'autorisation. Généralement, l'utilisateur entre l'ID et le mot de passe dans une fenêtre en incrustation du navigateur et le navigateur crée l'en-tête. Nécessite la configuration de SAF pour authentifier l'URL.
  • %%CERTIF%% : le serveur exécute la demande sous l'ID associé au certificat de client SSL dans SAF. S'il n'existe aucun certificat SSL ou si le certificat SSL n'a pas encore été associé à un ID dans SAF, le traitement se poursuit comme si %%CLIENT%% avait été codé. Ne nécessite pas la configuration de SAF authn ou authz.

    représentant-utilisateur : Le serveur remplace l'identité des unités d'exécution par un représentant d'utilisateur spécifique. Le serveur doit disposer d'un accès en lecture au profil BPX.SRV.représentant-utilisateur. Lorsque cette option est utilisée, le représentant d'utilisateur et l'ID d'origine du serveur Web doivent tous les deux avoir accès aux objets de système de fichiers demandés. Cette restriction est spécifique de cette méthode SAFRunAs et est une fonction du modèle de sécurité z/OS. Le serveur exécute la demande sous l'ID associé à l'ID de substitut SAF spécifié.

  • %%CERTIF_REQ%% : le serveur exécute la demande sous l'ID associé au certificat de client SSL dans SAF. S'il n'existe aucun certificat SSL ou si le certificat SSL n'a pas encore été associé à un ID dans SAF, le serveur ne permettra pas d'accès. Ne nécessite pas la configuration de SAF authn ou authz.

    <représentant-utilisateur> : Le serveur remplace l'identité des unités d'exécution par un représentant d'utilisateur spécifique. Le serveur doit disposer d'un accès en lecture à BPX.SRV."représentant-utilisateur". Lorsque cette option est utilisée, le représentant d'utilisateur et l'ID d'origine du serveur Web doivent tous les deux avoir accès aux objets de système de fichiers demandés. Cette restriction est spécifique de cette méthode SAFRunAs et est une fonction du modèle de sécurité z/OS.

    <représentant-utilisateur> : le serveur exécute la demande sous l'ID associé à l'ID de substitut SAF spécifié.

  • %%CERTIF%% /prefix : Le serveur remplace l'identité des unités d'exécution par l'identité fournie par l'authentification du client SSL pour les URL sous /prefix.
    Eviter les incidents Eviter les incidents:
    • Cette syntaxe est valide uniquement dans le contexte global et <virtualHost>.
    • Le serveur ne change pas les identités deux fois pendant une demande si SAFRunAs est également configuré en utilisant la version à un seul argument dans le contexte <Location> ou <Directory>.
    • Cette fonction peut être utilisée conjointement avec "AuthBasicProvider saf".
    gotcha
  • surrogate-username /prefix : Le serveur remplace l'identité des unités d'exécution par un ID utilisateur pour les URL sous /prefix.

    Lorsque cette option est utilisée, le représentant d'utilisateur et l'ID d'origine du serveur Web doivent tous les deux avoir accès aux objets de système de fichiers demandés. Cette restriction est spécifique de cette méthode SAFRunAs et est une fonction du modèle de sécurité z/OS.

    Eviter les incidents Eviter les incidents:
    • Cette syntaxe est valide uniquement dans le contexte global et <virtualHost>.
    • Le serveur ne change pas les identités deux fois pendant une demande si SAFRunAs est également configuré en utilisant la version à un seul argument dans le contexte <Location> ou <Directory>.
    • Cette fonction peut être utilisée conjointement avec "AuthBasicProvider saf".
    gotcha
  • <surrogate ID> : le serveur exécute la demande sous l'ID associé à l'ID de substitut SAF spécifié.

IBM HTTP Server peut communiquer avec des applications FastCGI en utilisant des sockets TCP ou UNIX. Toutefois, si vous utilisez SAFRunAs pour des demandes FastCGI, vous devez utiliser des sockets TCP pour pouvoir communiquer avec l'application. Les sockets UNIX créés pour des applications FastCGI sont accessibles uniquement par l'ID utilisateur du serveur Web. L'ID utilisateur substitut contrôlé par la directive SAFRunAs n'a pas les droits suffisants pour accéder aux sockets UNIX, d'où l'échec des demandes.

Pour configurer FastCGI de façon à utiliser des sockets TCP, définissez l'application FastCGI sur le module mod_fastcgi à l'aide de la directive FastCGIServer avec l'option -port ou à l'aide de la directive FastCGIExternalServer. Les serveurs FastCGI dynamiques que vous ne configurez pas avec les directives FastCGIServer ou FastCGIExternalServer ne peuvent pas être utilisés avec SAFRunAs.

Si vous n'activez pas SAFRunAs pour les demandes FastCGI, les sockets TCP ne sont pas requis.

Eviter les incidents Eviter les incidents: Vous pouvez configurer la directive SAFRunAS pour des ressources traitées avec la directive Action. Lorsque vous procédez ainsi, vous devez configurer la directive SAFRunAS sur une portée couvrant le deuxième paramètre de la directive Action plutôt que le chemin d'accès à la ressource d'origine.
Par exemple, une utilisation classique de la directive SAFRunAs se trouve dans la directive Location :
<Location /context-root-A/>
   SAFRunAS %%CLIENT%%
 </Location>
Les demandes sur les chemins contenant le paramètre /context-root-A/* s'exécutent en tant qu'utilisateur distant.
Cependant, lorsque vous utilisez également la directive Action, le serveur remplace la racine de contexte utilisée pour la correspondance.
# Process *.phtml with the "php-script" handler.
AddHandler php-script .phtml

# Define the "php-script" handler as an existing CGI.
Action php-script /cgi-bin/php-cgi
La directive Action transforme une demande du fichier /context-root-A/hello.phtml en demande d'un chemin d'accès contenant le paramètre /cgi-bin/php-cgi avec un argument de ligne de commande /context-root-A/hello.phtml.
Lorsque vous incluez la directive action, ajoutez une directive SAFRunAs à la directive Location, comme dans l'exemple suivant :
<Location /cgi-bin/php-cgi>
   SAFRunAS %%CLIENT%%
 </Location>

Si vous avez besoin de plusieurs paramètres SAFRunAs, n'utilisez pas la directive Action du tout ou créez plusieurs directives Action avec des paramètres secondaires différents.

gotcha

Directive SAFRunAsEarly

La directive SAFRunAsEarly permet à SAFRunAs de s'exécuter avant l'accès aux répertoires.

Directive Description
Syntaxe SAFRunAsEarly on | off
Valeur par défaut désactivé
Contexte location
Module mod_authnz_saf
Valeurs on | off
Lorsqu'une demande est reçue avec la valeur %%CLIENT%% affectée à SAFRunAs, IHS tente d'accéder au fichier à servir dans la réponse avant de changer d'ID utilisateur. Cela peut entraîner des problèmes lorsque certains répertoires/fichiers ne sont pas accessibles pour l'ID utilisateur sous lequel IHS est exécuté, mais sont accessibles pour l'utilisateur %%CLIENT%%. Une erreur telle que la suivante se produit lors de la tentative d'accès à ce type de répertoire :
[Tue Aug 11 14:03:16 2015] [error] [client x.x.x.x] (111)EDC5111I Permission denied. (errno2=0x5B4B0002): 
access to /saf/privileged/index.html deniedIf SAFRunAsEarly is set to on with SAFRunAs set to %%CLIENT%%, IHS will switch
user before any directory/file access are attempted.

Si SAFRunAsEarly est activée avec la valeur %%CLIENT%% affectée à SAFRunAs, IHS change d'utilisateur avant toute tentative d'accès à un répertoire/fichier.

Remarque :

SAFRunAsEarly doit être utilisée dans des contextes <Location> ou dans le contexte globale. Elle ne peut pas être utilisée dans des contextes <Directory>.

Si vous envisagez d'utiliser l'authentification et l'autorisation SAF, examinez l'exemple suivant. Il s'agit du scénario le plus courant pour les utilisateurs et les groupes SAF. Il respecte les exigences de l'accès Web.
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
...
<Location /saf_protected>
AuthType basic  
AuthName x1 
AuthBasicProvider saf 
# Codez "Require valid-user" si vous voulez qu'un utilisateur
# SAF valide puisse accéder à la ressource.
Require valid-user
#
# Vous pouvez également fournir la liste des utilisateurs SAF spécifiques
# qui peuvent accéder à la ressource.
# Les utilisateurs SAF USER84 USER85 sont requis
#
# Vous pouvez également fournir la liste des groupes SAF spécifiques
# dont les membres peuvent accéder à la ressource.
# Les groupes SAP WASGRP1 WASGRP2 sont requis
</Location>
Si vous souhaitez utiliser un fichier SAF pour l'authentification mais un groupe non SAF pour l'autorisation, examinez l'exemple suivant. Dans cet exemple, les utilisateurs sont authentifiés via SAF mais autorisés via un mécanisme différent.
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authnz_saf_module modules/mod_authnz_saf.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_default_module modules/mod_authz_default.so
...
<Location /saf_password>
AuthType basic
AuthName "aut SAF avec fichier de groupe hfs"
AuthBasicProvider saf
AuthGroupFile /www/config/foo.grp
# Codez "Require file-group" et la liste des groupes si vous voulez
# qu'un utilisateur de l'un quelconque des groupes du fichier de groupe spécifié soit en mesure
# d'accéder à la ressource.
# Remarque : n'importe quel module d'autorisation, avec sa configuration standard, peut être utilisé ici.
Require group admin1 admin2
</Location>
Si vous souhaitez autoriser l'accès à un utilisateur déjà autorisé par SAF ou par un fichier de groupe, examinez l'exemple suivant.
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authnz_saf_module modules/mod_authnz_saf.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_default_module modules/mod_authz_default.so
...
<Location /either_group>
AuthType basic
AuthName "aut SAF avec groupes SAF et fichier de groupe hfs"
AuthBasicProvider saf
AuthGroupFile /www/groupfiles/foo.grp
Require saf-group WASGRP
Require saf-group ADMINS
</Location>
Si vous souhaitez qu'une demande s'exécute avec les privilèges SAF associés au nom d'utilisateur authentifié, examinez l'exemple suivant.
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
...
<Location /runas_admin_bin>
AuthName "SAF RunAs client"
AuthType basic
Require valid-user
AuthBasicProvider saf
SAFRunAs %%CLIENT%%
</Location>
Si vous envisagez de prendre en charge la modification des mots de passe arrivés à expiration, examinez l'exemple suivant.
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
...
<Location /custom_password_change>
AuthType basic
AuthName "Prise en charge des mots de passe arrivés à expiration"
Require valid-user
AuthBasicProvider saf
AuthSAFEXpiration "EXPIRED PW: oldpw/newpw/newpw"
AuthSAFReEnter "Confirmer le nouveau mot de passe :"
</Location>

Si vous souhaitez demander un certificat client avant qu'un utilisateur ne puisse accéder à une ressource, utilisez la directive mod_ibm_ssl. La directive mod_authnz_saf n'est pas nécessaire pour cette configuration. Pour plus d'informations, consultez la documentation des directives SSLClientAuth et SSLClientAuthRequire.

Si vous envisagez d'utiliser un certificat client pour déterminer l'utilisateur pour lequel le traitement de la requête est réalisé, examinez l'exemple suivant. Si l'utilisateur ne dispose pas d'un certificat valide, l'accès est refusé.
LoadModule authnz_saf_module modules/mod_authnz_saf.so
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
...
<Location /certificate_required>
SAFRunAs %%CERTIF_REQ%%
</Location>
Si vous souhaitez qu'une demande s'exécute avec les privilèges SAF associés à un certificat client, mais souhaitez également demander l'authentification par nom d'utilisateur et par mot de passe si le certificat client n'est pas mappé sur un utilisateur SAF, examinez l'exemple suivant. Si l'utilisateur fournit un certificat que SAF peut mapper sur un ID utilisateur, ce dernier doit également transmettre les éventuelles directives Require.
<Location /certificate_or_basic>
AuthName "SAF RunAs certif"
AuthType basic
Require saf-user USER84 USER103
AuthBasicProvider saf
SAFRunAs %%CERTIF%%
</Location>
Si vous souhaitez qu'une demande s'exécute via les privilèges SAF associés à un ID de substitution, examinez l'exemple suivant.
<Location /runas_public>
SAFRunAs PUBLIC
# Cette commande peut être combinée avec l'authentification/autorisation SAF ou non-SAF
</Location>

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=ihs-dist&topic=rihs_safdirs
Nom du fichier : rihs_safdirs.html