Summary

This module allows FastCGI authorizer applications to
authenticate users and authorize access to resources. It supports
generic FastCGI authorizers which participate in a single phase
for authentication and authorization as well as Apache httpd-specific
authenticators and authorizors which participate in one or both
phases.

FastCGI authorizers can authenticate using user id and password,
such as for Basic authentication, or can authenticate using arbitrary
mechanisms.

Topics

See also

The invocation modes for FastCGI authorizers supported by this
module are distinguished by two characteristics, type and
auth mechanism.

Type is simply authn for authentication,
authz for authorization, or authnz for
combined authentication and authorization.

Auth mechanism refers to the Apache httpd configuration
mechanisms and processing phases, and can be
AuthBasicProvider, Require, or
check_user_id. The first two of these
correspond to the directives used to enable participation in the
appropriate processing phase.

Descriptions of each mode:

Typeauthn, mechanismAuthBasicProvider

In this mode,
FCGI_ROLE is set to AUTHORIZER and
FCGI_APACHE_ROLE is set to AUTHENTICATOR.
The application must be defined as provider type authn
using
AuthnzFcgiDefineProvider and enabled with
AuthBasicProvider.
When invoked, the application is
expected to authenticate the client using the provided user id and
password. Example application:

In this mode, FCGI_ROLE is set to
AUTHORIZER and FCGI_APACHE_ROLE is set to
AUTHORIZER. The application must be defined as
provider type authz using
AuthnzFcgiDefineProvider. When invoked, the application
is expected to authorize the client using the provided user id and other
request data. Example application:

In this mode, which supports the web server-agnostic FastCGI
AUTHORIZER protocol, FCGI_ROLE is set to
AUTHORIZER and FCGI_APACHE_ROLE is not set.
The application must be defined as provider type authnz
using
AuthnzFcgiDefineProvider. The application is expected to
handle both authentication and authorization in the same invocation
using the user id, password, and other request data. The invocation
occurs during the Apache httpd API authentication phase. If the
application returns 200 and the same provider is invoked during the
authorization phase (via Require), mod_authnz_fcgi
will return success for the authorization phase without invoking the
application. Example application:

The following are potential features which are not currently
implemented:

Apache httpd access checker

The Apache httpd API access check phase is a separate
phase from authentication and authorization. Some other FastCGI
implementations implement this phase, which is denoted by the
setting of FCGI_APACHE_ROLE to ACCESS_CHECKER.

Local (Unix) sockets or pipes

Only TCP sockets are currently supported.

Support for mod_authn_socache

mod_authn_socache interaction should be implemented for
applications which participate in Apache httpd-style
authentication.

Support for digest authentication using AuthDigestProvider

This is expected to be a permanent limitation as there is
no authorizer flow for retrieving a hash.

Application process management

This is expected to be permanently out of scope for
this module. Application processes must be controlled by
other means. For example, fcgistarter can be used to
start them.

AP_AUTH_INTERNAL_PER_URI

All providers are currently registered as
AP_AUTH_INTERNAL_PER_CONF, which means that checks are not
performed again for internal subrequests with the same
access control configuration as the initial request.

Protocol data charset conversion

If mod_authnz_fcgi runs in an EBCDIC compilation
environment, all FastCGI protocol data is written in EBCDIC
and expected to be received in EBCDIC.

Multiple requests per connection

Currently the connection to the FastCGI authorizer is
closed after every phase of processing. For example, if the
authorizer handles separate authn and authz
phases then two connections will be used.

URI Mapping

URIs from clients can't be mapped, such as with the
ProxyPass used with FastCGI responders.

Environment variables passed to the application are
logged at log level trace2. The value of the
REMOTE_PASSWD variable will be obscured,
but any other sensitive data will be visible in the
log.

All I/O between the module and the FastCGI application,
including all environment variables, will be logged in printable
and hex format at log level trace5. All
sensitive data will be visible in the log.

LogLevel can be used
to configure a log level specific to mod_authnz_fcgi. For
example:

This directive is used to enable a FastCGI authorizer to
handle a specific processing phase of authentication or
authorization.

Some capabilities of FastCGI authorizers require enablement
using this directive instead of
AuthBasicProvider:

Non-Basic authentication; generally, determining the user
id of the client and returning it from the authorizer; see the
UserExpr option below

Selecting a custom response code; for a non-200 response
from the authorizer, the code from the authorizer will be the
status of the response

Setting the body of a non-200 response; if the authorizer
provides a response body with a non-200 response, that body
will be returned to the client; up to 8192 bytes of text are
supported

provider-name

This is the name of a provider defined with
AuthnzFcgiDefineProvider.

None

Specify None to disable a provider enabled
with this directive in an outer scope, such as in a parent
directory.

option

The following options are supported:

Authoritative On|Off (default On)

This controls whether or not other modules are allowed
to run when this module has a FastCGI authorizer configured
and it fails the request.

DefaultUser userid

When the authorizer returns success and UserExpr
is configured and evaluates to an empty string (e.g., authorizer
didn't return a variable), this value will be used as the user
id. This is typically used when the authorizer has a concept of
guest, or unauthenticated, users and guest users are mapped to
some specific user id for logging and other purposes.

RequireBasicAuth On|Off (default Off)

This controls whether or not Basic auth is required
before passing the request to the authorizer. If required,
the authorizer won't be invoked without a user id and
password; 401 will be returned for a request without that.

UserExpr expr (no default)

When Basic authentication isn't provided by the client
and the authorizer determines the user, this expression,
evaluated after calling the authorizer, determines the
user. The expression follows
ap_expr syntax and must resolve to a string. A typical
use is to reference a Variable-XXX
setting returned by the authorizer using an option like
UserExpr "%{reqenv:XXX}". If
this option is specified and the user id can't be retrieved
using the expression after a successful authentication, the
request will be rejected with a 500 error.

Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.