Introduction

For each directive, this chapter gives several types of information:

For each directive, the Context field gives one of three possible contexts, each denoting a level in the configuration hierarchy:

Context Description
server Server directives apply to the site in general and must appear outside containers.
host Host directives can appear within <VirtualHost> containers or in the general server configuration.
object Object directives can appear within <Directory>, <Location>, <File>, or <Limit> containers, as well as .htaccess files. They can also appear in <VirtualHost> containers or in the general server configuration.

Although many directives can appear in more than one context, only one is given for each. The given context is the narrowest one in which the directive can appear; it can also appear in any larger context.

Each directive listing also specifies the module controlled by that directive. If a directive applies to the core Apache server and not to any module, "core" is listed instead of a module name. If you add or remove modules, be sure to comment out the directives that pertain to it, or use the <IfModule> container to configure modules conditionally.



What does Apache RADIUS Authentication Module do


Features of the Apache RADIUS Authentication Module:

  • RADIUS authentication. It can query a RADIUS server to authenticate  a user based on his/her username and (one-time) password.

  • RADIUS authorization.

    If the authentication was succesfull. It can
    based on special RADIUS attributes that were send back to the
    Apache Webserver, decide whether a user has access to the
    requested pages.

    But is has more directives on which it cat give authorization.
    like realm, traditional group files, No realm (local user),
    Successfull authentication.

    You can also exclude certain people.

    How is it done:

    Authentication:

    When you connect to the web server the server the Radius authentication module checks for a cookie.

    1. If there is a cookie the module will check if it is a valid cookie.

      A valid cookie is a cookie which, can be reproduced(see cookie format) and has not expired. A cookie is expired if the current time is larger then the expire time which was derrived from the cookie see cookie format.

      If the cookie is invalid see 2.

      If the cookie is valid see 3.
    2. If there is no (valid) cookie the webserver  will send a authentication request (401) back to the web brouwser.

      The user types his username (email address) and this password and  the are send back to the webserver.

      The username password combination is then send as a Radius request to a Radius (proxy) server.

      If the Radius authentication request was succesfull the Radius packet is then checked for special attributes. These special attributes can hold the group id which can represend authorization levels the user has.

      A cookie is then generated and send later to the brouwser as is http "Set-Cookie:" header with a Cookie expire date set to 1-1-1970.  The http request is then handed over to the authorization part of the module (1.3).
    3. The authorization part of the module check if the username or one of the groupid's match the pre configured apache "require" directives.

      If the username/groupid's match one of the directives tha requested web page is send to the web browser.

      If there is a directive "require valid-user" the page is send to the user if the authentication was succesfull.

  • Radius Group authorization.

    Authorization via groupid can be done by the radius server sending     back radius attributes which contain group-id's. A Radius authentication request can hold 1 or more shuch attirbues:

                    Service-Type = Authenticate-Only
                    Group-ID = 1
                    Group-ID = 3
                    Group-ID = 4
                    'brendan@banzai.nl.net' authentication OK

    With this succesfull authentication request 3 group-id's where
    sendback to the Radius client.

    These group-id's are put into the Cookie as a 32bit number which
    is send allong with the web page to the browser.

    To make live easier on the configuration people. You can specify a
    groupfile that maps these groupid's to groupnames:

    If the directory directive in apache says:

    require radgroup sales

    and in the dictionary says:


    ATTRIBUTE       Group-ID                 81       integer

    # example values for ATTRIBUTE Group-ID
    VALUE          Group-ID                 Executive        1
    VALUE          Group-ID                 Sales               2
    VALUE          Group-ID                 Marketing        3
    VALUE          Group-ID                 Operations       4



    If the radius reqest which was send back to the web brouwser holds the Group-ID 2. The user may access these pages.

     The radgroup require directive matches numbers and/or string representatives of those numbers.

    I would realy like to standardize these group-id's between all opco's.

    Please note that you can still use the standard apache way of group access see Require group.

Cookie Format:

   The cookie has to have the following syntax.

        md5digest,expiretime,groupid's

        32bytes:
        md5digest(secret, md5digest(secret, "username,
                                user password,
                                special server secret*,
                                client ip number,
                                hostname,
                                expires (seconds since 1-1-1970),
                                group_id (string discribed below)

        8bytes expires time (seconds since 1-1-1970)

        string beginging and ending with a '$' character make up outof
        multiple 8bytes seperated by a '$'. The multiple 8bytes strings
        seperated by a '$' represend (hex) group ID integers

        So the cookie will look like:

 


38f088b5215c674d59514ae1b9e378f83575c7cd$0000012c$0000012d$0000012e$ etc
................................--------$========$========$========$

        . digest
        - expiretime (hex)
        $ seperator
        = groupids (hex)

        (*) 16 byte random character sequence generated every time the
            server starts.



Getting the Source And Compiling


Compliling the stuff is straghtforward. Fetch the latest apache sources from www.apache.org. Untar the complete distribution and follow the compilation instruction.

Apply this patch to the Apache sourcecode apache.patch if you
are going to use this apache as a proxy server. This will fix the fact that the 'proxing' webserver does not send the cookie back to the client


Install mod_auth_radius.c in a directory. and type:

    $ apxs -g -n auth_radius
Creating [DIR]  auth_radius
Creating [FILE] auth_radius/Makefile
Creating [FILE] auth_radius/mod_auth_radius.c
check that a directory is created which is named auth_radius
replace auth_radius/mod_auth_radius.c with mod_auth_radius.c

Apply this  patch to the Apache sourcecode apache.patch .
Ensure that apache in compiled with the -lresolv libraries from bind!.

General Configuration

The following drectives are avalable:

Radius module setup directives

AddRadiusAuth

AddRadiusCookieValid

AddRadiusGroupidAttirbuteNumber

RadiusDictionary

AuthRadiusNetMaskFile

RadiusLog

RadiusDefaultRealm

AuthRadiusCaseConvert

RadiusTrustServer



Radius module Authentication Setup

AuthRadiusAuthoritative

AuthRadiusCheckexists

RadiusReauthenticate

AuthRadiusGroupFile

AuthRadiusCookieValid



Authconfig Setup

This authorization setup is differend from the standard apache configurations in respect to the the fact that you can explisitly deny users from vieuwing your content, revieuw the folloing syntax. 

    <Directory gnarst/workfloor/gossip> 

	...

	AuthRadiusGroupFile /etc/gnarst.groupfile
	require realm @uk.gnarst.net
	require not group executive
	require user andrewc@uk.gnarst.net
	require realm @lusers.gnarst.net internal
</Directory>

In this example the directory gnarst/workfloor/gossip can be accessed by anyone that has a realm '@uk.gnarst.net'. But if the user belongs to the group executive access will be denied. This group file in this case is a file that lives on the webserver itself /usr/local/www/gnarst.groupfile. And may hold the following lines. 

    executive: pat@uk.gnarst.net luc@uk.gnarst.net
users with an @lusers.gnarst.net realm can only connect from networks which match the tag internal. In the AuthRadiusNetMaskFile you can configure the tag's and the networks where clients can connect from. (see AuthRadiusNetMaskFile)
If multiple directive are specified you should read like this. 


        ( realm @uk.gnarst.net AND NOT group executive ) 
	OR 
	( user andrewc@uk.gnarst.net 
		AND not group executive )

So if the user matches andrewc@uk.gnarst.net and belongs to the group executive in the group file /usr/local/www/gnarst.groupfile andrewc@uk.gnarst.net will be denied access.

valid-user

radgroup

group

realm

norealm