Configuring Apache and KX509

Our authentication support for kx509 in Apache is based around the locally written mod_authssl module. mod_authssl provides a mechanism for web applications to use the information contained in X509 client certificates to populate the REMOTE_USER variable, in the same way as the classic 'Basic' authentication mechanism would. In addition, it allows the username information embedded within the certificates to be put through the standard Apache authz stack, allowing the use of 'require ', groups and the like.

Configuration directives

  • AuthSSLEnable Set this to 'on' to enable the checking of X509 certificates. Setting this, without adding any explicit access control directives will just populate the REMOTE_USER variable when the user has a certificate which matches the defined issuer.

  • AuthSSLDNComponent Set this to the component of the DN which is to be extracted and used as the clients username. If this is not set, the client's full DN will be user. DN components are named in the same way as they appear in the server's environment - for instance the UID is SSL_CLIENT_S_DN_UID

  • AuthSSLIssuer Set this to the subject DN in your CA's certificate. This is the issuer DN on a client certificate signed by that CA. Only certificates whose issuer exactly matches this string will be accepted.

  • AuthSSLAuthoritative Set this to 'on' to make the authssl module the last check in checking a user's access. This allows the module to return a 'FORBIDDEN' response, which can be trapped and redirected to another page, without prompting the user in the same was as the standard 'authenticateion required' response. If you're not chaining access modules, then you want this.

Examples

The following discuss a number of different ways of using mod_authssl.

Password replacement

Neil's notes at http://www.dice.inf.ed.ac.uk/groups/services/web/docs/kx509.html are fairly exhaustive in terms of ways of using mod_authssl to replace password files.

Opportunistic authentication

The mod_authssl module can also be used in 'opportunistic' mode, where a user is authenticated and the REMOTE_USER variable set if they present a valid certificate, but if they don't access is still granted to the resource, but without REMOTE_USER being set. This is useful for applications such as TWiki which can benefit from knowing the username, but wich don't require it, and for chaining multiple authentication types (see below).

The .htaccess file for opportunistic use looks something like:

AuthSSLEnable           on
AuthSSLDNComponent      SSL_CLIENT_S_DN_UID
AuthSSLIssuer           "/C=GB/ST=Scotland/O=School of Informatics, University of Edinburgh/OU=Ephemeral Key Certification Agency/CN=kx509 CA"

Authentication Chaining

Carwyn did some work on getting both SSL and Basic authentication working for the LCFG web server. In this case, Basic auth will be used if the client doesn't present a valid SSL certificate.

AuthName             "Authentication realm"
AuthType             Basic
AuthSSLEnable        on
AuthSSLDNComponent   SSL_CLIENT_S_DN_UID
AuthSSLIssuer        "/C=GB/ST=Scotland/O=School of Informatics, University of Edinburgh/OU=Ephemeral Key Certification Agency/CN=kx509 CA"
AuthSSLAuthoritative off

Require valid-user

-- SimonWilkinson - 04 Apr 2005

Topic revision: r1 - 04 Apr 2005 - 00:44:34 - SimonWilkinson
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies