Serveur HTTP Apache Version 2.5

Apache > Serveur HTTP > Documentation > Version 2.5 > Modules

# Module Apache mod_authnz_fcgi

Description: | Permet Ã une application d'autorisation FastCGI de gÃ©rer l'authentification et l'autorisation httpd.
Statut: | Extension
Identificateur de Module: | authnz_fcgi_module
Fichier Source: | mod_authnz_fcgi.c
Compatibilité: | Disponible Ã partir de la version 2.4.10 du serveur HTTP Apache

### Sommaire

Ce module permet aux applications d'autorisation FastCGI d'authentifier les utilisateurs et de contrÃ´ler leur accÃ¨s aux ressources. Il supporte les systÃ¨mes d'autorisation FastCGI gÃ©nÃ©riques qui participent en une seule phase Ã l'authentification et Ã l'autorisation, ainsi que les processus d'authentification et d'autorisation spÃ©cifiques Ã Apache httpd qui interviennent en une ou plusieurs phases.

Les processus d'autorisation FastCGI peuvent authentifier un utilisateur via son identificateur et son mot de passe comme dans le processus d'authentification basique, ou via un mÃ©canisme arbitraire.

### Sujets

- Modes d'invocation
- Exemples supplÃ©mentaires
- Limitations
- Journalisation

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

### Voir aussi

- Authentification, autorisation et contrÃ´le d'accÃ¨s
- `mod_auth_basic`
- `fcgistarter`
- `mod_proxy_fcgi`

## Modes d'invocation ¶

Les modes d'invocation des processus d'autorisation FastCGI que ce module supporte se distinguent par deux caractÃ©ristiques : le type et le mÃ©canisme d'authentification.

Le Type est simplement `authn` pour l'authentification, `authz` pour l'autorisation et `authnz` l'authentification et l'autorisation.

Le mÃ©canisme d'authentification fait rÃ©fÃ©rence aux mÃ©canismes d'authentification et aux phases de traitement de la configuration de Apache httpd, et peut Ãªtre `AuthBasicProvider`, `Require`, ou `check_user_id`. Les deux premiers mÃ©canismes correspondent aux directives utilisÃ©es pour participer aux phases de traitement appropriÃ©es.

Description de chaque mode:

Type `authn`, mechanism `AuthBasicProvider`
  Dans ce mode, la variable `FCGI_ROLE` est dÃ©finie Ã `AUTHORIZER`, et la variable `FCGI_APACHE_ROLE` Ã `AUTHENTICATOR`. L'application doit Ãªtre spÃ©cifiÃ©e en tant que fournisseur de type authn via la directive `AuthnzFcgiDefineProvider`, et activÃ©e via la directive `AuthBasicProvider`. Lorsqu'elle est invoquÃ©e, l'application est censÃ©e authentifier le client Ã l'aide de l'identifiant et du mot de passe de l'utilisateur. Exemple d'application :

      #!/usr/bin/perl
      use FCGI;
      my $request = FCGI::Request();
      while ($request->Accept() >= 0) {
          die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
          die if $ENV{'FCGI_ROLE'}        ne "AUTHORIZER";
          die if !$ENV{'REMOTE_PASSWD'};
          die if !$ENV{'REMOTE_USER'};

          print STDERR "This text is written to the web server error log.\n";

          if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
              $ENV{'REMOTE_PASSWD'} eq "bar" ) {
              print "Status: 200\n";
              print "Variable-AUTHN_1: authn_01\n";
              print "Variable-AUTHN_2: authn_02\n";
              print "\n";
          }
          else {
              print "Status: 401\n\n";
          }
      }

  Exemple de configuration httpd :

      AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/
      <Location "/protected/">
        AuthType Basic
        AuthName "Restricted"
        AuthBasicProvider FooAuthn
        Require ...
      </Location>

Type `authz`, mechanism `Require`
  Dans ce mode, la variable `FCGI_ROLE` est dÃ©finie Ã `AUTHORIZER` et `FCGI_APACHE_ROLE` Ã `AUTHORIZER`. L'application doit Ãªtre spÃ©cifiÃ©e en tant que fournisseur de type authz via la directive `AuthnzFcgiDefineProvider`. Lorsqu'elle est invoquÃ©e, l'application est censÃ©e contrÃ´ler les accÃ¨s du client Ã l'aide de l'identifiant utilisateur et d'autres donnÃ©es contenues dans la requÃªte. Exemple d'application :

      #!/usr/bin/perl
      use FCGI;
      my $request = FCGI::Request();
      while ($request->Accept() >= 0) {
          die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHORIZER";
          die if $ENV{'FCGI_ROLE'}        ne "AUTHORIZER";
          die if $ENV{'REMOTE_PASSWD'};

          print STDERR "This text is written to the web server error log.\n";

          if ($ENV{'REMOTE_USER'} eq "foo1") {
              print "Status: 200\n";
              print "Variable-AUTHZ_1: authz_01\n";
              print "Variable-AUTHZ_2: authz_02\n";
              print "\n";
          }
          else {
              print "Status: 403\n\n";
          }
      }

  Exemple de configuration httpd :

      AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10103/
      <Location "/protected/">
        AuthType ...
        AuthName ...
        AuthBasicProvider ...
        Require FooAuthz
      </Location>

Type `authnz`, mechanism `AuthBasicProvider` + `Require`
  Dans ce mode qui supporte le protocole d'autorisation web server-agnostic FastCGI, la variable `FCGI_ROLE` est dÃ©finie Ã `AUTHORIZER` et `FCGI_APACHE_ROLE` n'est pas dÃ©finie. L'application doit Ãªtre spÃ©cifiÃ©e en tant que fournisseur de type authnz via la directive `AuthnzFcgiDefineProvider`. L'application est censÃ©e assurer l'authentification et l'autorisation au cours d'une mÃªme invocation Ã l'aide de l'identifiant et du mot de passe de l'utilisateur et d'autres donnÃ©es contenues dans la requÃªte. L'invocation de l'application intervient au cours de la phase d'authentification de l'API Apache httpd. Si l'application renvoie le code 200, et si le mÃªme fournisseur est invoquÃ© au cours de la phase d'autorisation (via une directive `Require`), mod_authnz_fcgi renverra un code de type success pour la phase d'autorisation sans invoquer l'application. Exemple d'application :

      #!/usr/bin/perl
      use FCGI;
      my $request = FCGI::Request();
      while ($request->Accept() >= 0) {
          die if $ENV{'FCGI_APACHE_ROLE'};
          die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
          die if !$ENV{'REMOTE_PASSWD'};
          die if !$ENV{'REMOTE_USER'};

          print STDERR "This text is written to the web server error log.\n";

          if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
              $ENV{'REMOTE_PASSWD'} eq "bar" &&
              $ENV{'REQUEST_URI'} =~ m%/bar/.*%) {
              print "Status: 200\n";
              print "Variable-AUTHNZ_1: authnz_01\n";
              print "Variable-AUTHNZ_2: authnz_02\n";
              print "\n";
          }
          else {
              print "Status: 401\n\n";
          }
      }

  Exemple de configuration httpd :

      AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
      <Location "/protected/">
        AuthType Basic
        AuthName "Restricted"
        AuthBasicProvider FooAuthnz
        Require FooAuthnz
      </Location>

Type `authn`, mechanism `check_user_id`
  Dans ce mode, la variable `FCGI_ROLE` est dÃ©finie Ã `AUTHORIZER` et `FCGI_APACHE_ROLE` Ã `AUTHENTICATOR`. L'application doit Ãªtre spÃ©cifiÃ©e en tant que fournisseur de type authn via une directive `AuthnzFcgiDefineProvider`. La directive `AuthnzFcgiCheckAuthnProvider` permet de l'invoquer. Exemple d'application :

      #!/usr/bin/perl
      use FCGI;
      my $request = FCGI::Request();
      while ($request->Accept() >= 0) {
          die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
          die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";

          # This authorizer assumes that the RequireBasicAuth option of
          # AuthnzFcgiCheckAuthnProvider is On:
          die if !$ENV{'REMOTE_PASSWD'};
          die if !$ENV{'REMOTE_USER'};

          print STDERR "This text is written to the web server error log.\n";

          if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
              $ENV{'REMOTE_PASSWD'} eq "bar" ) {
              print "Status: 200\n";
              print "Variable-AUTHNZ_1: authnz_01\n";
              print "Variable-AUTHNZ_2: authnz_02\n";
              print "\n";
          }
          else {
              print "Status: 401\n\n";
              # If a response body is written here, it will be returned to
              # the client.
          }
      }

  Exemple de configuration httpd :

      AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10103/
      <Location "/protected/">
        AuthType ...
        AuthName ...
        AuthnzFcgiCheckAuthnProvider FooAuthn \
                                     Authoritative On \
                                     RequireBasicAuth Off \
                                     UserExpr "%{reqenv:REMOTE_USER}"
        Require ...
      </Location>

## Exemples supplÃ©mentaires ¶

1. Si votre application supporte sÃ©parÃ©ment les rÃ´les d'authentification et d'autorisation (`AUTHENTICATOR` et `AUTHORIZER`), vous pouvez dÃ©finir des fournisseurs sÃ©parÃ©s comme suit, mÃªme s'ils correspondent Ã la mÃªme application :

       AuthnzFcgiDefineProvider authn  FooAuthn  fcgi://localhost:10102/
       AuthnzFcgiDefineProvider authz  FooAuthz  fcgi://localhost:10102/

   SpÃ©cifie le fournisseur authn via la directive `AuthBasicProvider` et le fournisseur authz via la directive `Require`:

       AuthType Basic
       AuthName "Restricted"
       AuthBasicProvider FooAuthn
       Require FooAuthz

2. Si votre application supporte le rÃ´le gÃ©nÃ©rique `AUTHORIZER` (authentification et autorisation en une seule invocation), vous pouvez dÃ©finir un fournisseur unique comme suit :

       AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/

   SpÃ©cifie le fournisseur authnz via les directives `AuthBasicProvider` et `Require` :

       AuthType Basic
       AuthName "Restricted"
       AuthBasicProvider FooAuthnz
       Require FooAuthnz

## Limitations ¶

Les fonctionnalitÃ©s suivantes ne sont pas encore implÃ©mentÃ©es :

VÃ©rificateur d'accÃ¨s d'Apache httpd
  La phase access check de l'API Apache httpd est distincte des phases d'authentification et d'autorisation. Certaines autres implÃ©mentations de FastCGI supportent cette phase et lorsque c'est le cas, la variable `FCGI_APACHE_ROLE` est dÃ©finie Ã `ACCESS_CHECKER`.
Redirections (pipes) ou sockets locaux (Unix)
  Seuls les sockets TCP sont actuellement supportÃ©s.
Support de mod_authn_socache
  Le support de l'interaction avec mod_authn_socache pour les applications qui interviennent dans le processus d'authentification d'Apache httpd serait souhaitable.
Support de l'authentification de type digest Ã l'aide de AuthDigestProvider
  Cette limitation ne sera probablement jamais franchie car il n'existe aucun flux de donnÃ©es d'autorisation capable de lire dans un condensÃ© de type hash.
Gestion des processus applicatifs
  Cette fonctionnalitÃ© restera probablement hors de portÃ©e de ce module. Il faudra donc gÃ©rer les processus applicatifs d'une autre maniÃ¨re ; par exemple, `fcgistarter` permet de les dÃ©marrer.
AP_AUTH_INTERNAL_PER_URI
  Tous les fournisseurs sont actuellement enregistrÃ©s en tant que AP_AUTH_INTERNAL_PER_CONF, ce qui signifie que les vÃ©rifications ne sont pas effectuÃ©es pour les sous-requÃªtes internes avec la mÃªme configuration de contrÃ´le d'accÃ¨s que la requÃªte initiale.
Conversion du jeu de caractÃ¨res des donnÃ©es de protocole
  Si mod_authnz_fcgi s'exÃ©cute dans un environnement de compilation EBCDIC, toutes les donnÃ©es de protocole FastCGI sont Ã©crites en EBCDIC et doivent Ãªtre disponibles en EBCDIC.
Plusieurs requÃªtes pour une connexion
  Actuellement, la connexion au fournisseur d'autorisation FastCGI est fermÃ©e aprÃ¨s chaque phase de traitement. Par exemple, si le fournisseur d'autorisation gÃ¨re sÃ©parÃ©ment les phases authn et authz, deux connexions seront nÃ©cessaires.
Redirection de certains URIs
  Les URIs en provenance des clients ne peuvent pas Ãªtre redirigÃ©s selon une table de redirection, comme avec la directive `ProxyPass` utilisÃ©e avec les rÃ©pondeurs FastCGI.

## Journalisation ¶

1. Les erreurs de traitement sont journalisÃ©es Ã un niveau `error` ou supÃ©rieur.
2. Les messages envoyÃ©s par l'application sont journalisÃ©s au niveau `warn`.
3. Les messages de deboguage Ã caractÃ¨re gÃ©nÃ©ral sont journalisÃ©s au niveau `debug`.
4. Les variables d'environnement transmises Ã l'application sont journalisÃ©es au niveau `trace2`. La valeur de la variable `REMOTE_PASSWD` sera occultÃ©e, mais toute autre donnÃ©e sensible sera visible dans le journal.
5. Toutes les entrÃ©es/sorties entre le module et l'application FastCGI, y compris les variables d'environnement, seront journalisÃ©es au format imprimable et hexadÃ©cimal au niveau `trace5`. Toutes les donnÃ©es sensibles seront visibles dans le journal.

La directive `LogLevel` permet de configurer un niveau de journalisation spÃ©cifique Ã mod_authnz_fcgi. Par exemple :

    LogLevel info authnz_fcgi:trace8

## Directive AuthnzFcgiCheckAuthnProvider ¶

Description: | Permet Ã une application FastCGI de gÃ©rer l'accroche d'authentification check_authn.
Syntaxe: | `AuthnzFcgiCheckAuthnProvider provider-name|`None` option ...`
Défaut: | `none`
Contexte: | répertoire
Surcharges autorisées: | FileInfo
Statut: | Extension
Module: | mod_authnz_fcgi

Cette directive permet de confier Ã une application FastCGI la gestion d'une phase spÃ©cifique du processus d'authentification ou d'autorisation.

Certaines fonctionnalitÃ©s des fournisseurs d'autorisation FastCGI nÃ©cessitent cette directive en lieu et place de `AuthBasicProvider` pour pouvoir Ãªtre activÃ©es :

- L'authentification de type autre que basique ; en gÃ©nÃ©ral, dÃ©termination de l'identifiant utilisateur et renvoi de sa valeur depuis le fournisseur d'autorisation ; voir l'option `UserExpr` ci-dessous
- SÃ©lection d'un code de rÃ©ponse personnalisÃ© ; en cas de code de rÃ©ponse autre que 200 en provenance du fournisseur d'autorisation, c'est ce code qui sera utilisÃ© comme code d'Ã©tat de la rÃ©ponse
- DÃ©finition du corps d'une rÃ©ponse autre que 200 ; si le fournisseur d'autorisation renvoie un corps de rÃ©ponse avec un code autre que 200, c'est ce corps de rÃ©ponse qui sera renvoyÃ© au client ; la longueur du texte est limitÃ©e Ã 8192 octets

provider-name
  C'est le nom du fournisseur dÃ©fini au prÃ©alable via la directive `AuthnzFcgiDefineProvider`.
`None`
  SpÃ©cifiez `None` pour dÃ©sactiver un fournisseur activÃ© avec cette mÃªme directive dans une autre portÃ©e, par exemple dans un rÃ©pertoire parent.
option
  Les options suivantes sont supportÃ©es :
  Authoritative On|Off (par dÃ©faut On)
    Cette option permet de dÃ©finir si l'appel Ã d'autres modules est autorisÃ© lorsqu'un fournisseur d'autorisation FastCGI a Ã©tÃ© configurÃ© et si la requÃªte Ã©choue.
  DefaultUser id utilisateur
    Lorsque le fournisseur d'autorisation donne son accord, et si `UserExpr` est dÃ©fini et correspond Ã une chaÃ®ne vide, (par exemple, si le fournisseur d'autorisation ne renvoie aucune variable), c'est cette valeur qui sera utilisÃ©e comme id utilisateur par dÃ©faut. Cela se produit souvent lorsqu'on se trouve dans un contexte d'invitÃ©, ou d'utilisateur non authentifiÃ© ; les utilisateurs et invitÃ©s se voient alors attribuÃ© un id utilisateur spÃ©cifique qui permettra de se connecter et d'accÃ©der Ã certaines ressources.
  RequireBasicAuth On|Off (par dÃ©faut Off)
    Cette option permet de dÃ©finir si l'authentification basique est requise avant de transmettre la requÃªte au fournisseur d'autorisation. Dans l'affirmative, le fournisseur d'autorisation ne sera invoquÃ© qu'en prÃ©sence d'un id utilisateur et d'un mot de passe ; si ces deux Ã©lÃ©ments ne sont pas prÃ©sents, un code d'erreur 401 sera renvoyÃ©
  UserExpr expr (pas de valeur par dÃ©faut)
    Lorsque le client ne fournit pas l'authentification basique et si le fournisseur d'autorisation dÃ©termine l'id utilisateur, cette expression, Ã©valuÃ©e aprÃ¨s l'appel au fournisseur d'autorisation, permet de dÃ©terminer l'id utilisateur. Cette expression se conforme Ã la syntaxe ap_expr et doit correspondre Ã une chaÃ®ne de caractÃ¨res. Une utilisation courante consiste Ã rÃ©fÃ©rencer la dÃ©finition d'une `Variable-XXX` renvoyÃ©e par le fournisseur d'autorisation via une option du style `UserExpr "%{reqenv:XXX}"`. Si cette option est spÃ©cifiÃ©e, et si l'id utilisateur ne peut pas Ãªtre dÃ©finie via l'expression aprÃ¨s une authentification rÃ©ussie, la requÃªte sera rejetÃ©e avec un code d'erreur 500.

## Directive AuthnzFcgiDefineProvider ¶

Description: | DÃ©finit une application FastCGI en tant que fournisseur d'authentification et/ou autorisation
Syntaxe: | `AuthnzFcgiDefineProvider type provider-name backend-address`
Défaut: | `none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_authnz_fcgi

Cette directive permet de dÃ©finir une application FastCGI en tant que fournisseur pour une phase particuliÃ¨re d'authentification ou d'autorisation.

type
  Les valeurs de ce paramÃ¨tre sont authn pour l'authentification, authz pour l'autorisation, ou authnz pour un fournisseur d'autorisation gÃ©nÃ©rique FastCGI qui effectue les deux vÃ©rifications.
provider-name
  Ce paramÃ¨tre permet d'associer un nom au fournisseur ; ce nom pourra Ãªtre utilisÃ© dans des directives comme `AuthBasicProvider` et `Require`.
backend-address
  Ce paramÃ¨tre permet de spÃ©cifier l'adresse de l'application sous la forme fcgi://hostname:port/. Le ou les processus de l'application doivent Ãªtre gÃ©rÃ©s indÃ©pendamment comme avec `fcgistarter`.