Attribute Filtering Module


-1. CAVEAT


RLM_ATTR_FILTER

0.  INTRODUCTION

  This module exists for filtering certain attributes and values in received
  radius packets from remote proxy servers.  It gives the proxier (us) a very
  flexible framework to filter the attributes that proxy servers send us in
  their replies.  This makes sense in an out-sourced dialup situation for
  example, where the client proxy is permitted only certain values for setting
  the Idle-Timeout.

  Filter rules are defined and applied on a per-realm basis, where the realm
  can be anything you have defined via the rlm_realm module.

1.  MODULE CONFIGURATION

  The module configuration section is very simple.  There is only one attribute
  that needs to be set, the file to read the filter rules from.

  As an example, here is the default configuration from radiusd.conf:

       modules {
           ...
           attr_filter {
		attrsfile = ${confdir}/attrs
	   }
           ...
       }

  If attrsfile is not specified, it defaults to the above configuration.

  This module supports multiple named instances per the normal method.

  Once defined in the modules section of the config file, you must add the
  module instance name ( the name of the module itself by default ) into the  
  'authorize{}' section.  It should be placed *before* the realm modules.

  As an example:
  
       authorize {
           preprocess
           attr_filter
           realm
	   files
       }

  If the incoming packet is not a proxy reply, the module returns a NOOP,
  so that the rest of the 'authorize{}' is called normally.

3.  MODULE OPTIONS

  The file that defines the attribute filter rules is layed out and parsed
  very similar to the users file.  There are a couple main differences:

     o  There are no "check items" on the first line of the profile other
        than the "realm".

     o  There is only one DEFAULT entry.  This is due to the fact that there
        are no "check items" beyond the realm name.  Fall-Through does work
        though, allowing you to put the commonly allowed attribute rules into
        the DEFAULT entry and only put realm specific rules in the specific
        realm entry.

     o  The operators used for specifying the attributes are as follows:

           =    -  NOT ALLOWED.  If used, it becomes "=="

           :=   -  Set ( used to ensure a specific a/v is present )
           ==   -  Equal  ( exact )
	   =*   -  Always Equal ( will allow all values for attribute )
           !*   -  Always Not Equal ( will block all values for attribute )
           !=   -  Not equal
           >=   -  Greater than or equal to
           <=   -  Less than or equal to
           >    -  Greater than
           <    -  Less than

           If you have regular expressions enabled you also have:

           =~   -  Regular expression equal
           !~   -  Regular expression not equal


  See the comments in the default 'attrs' file for examples and additional
  explanation.

4.  MODULE FUNCTION

  The way the module works is as follows:

     o  Build a list of a/v pair rules from the 'attrs' file at module
        instantiation.

     o  When a proxy reply packet is received and passed to the module, it
        checks for a Realm attribute in the original request a/v pairs.
        ( The Realm attribute is added there by the proxy code ).

     o  The module walks the list of a/v pair rules until it finds a
        match for the Realm value or it reaches the DEFAULT entry.

     o  If there are any rules with SET operators, those attributes are 
	added to the top of a temporary reply list.
 
     o  Each a/v pair in the proxy reply is compared to the list of 
	rules.
   
     o  If an a/v pair in the proxy reply passes *ALL* of the rules that
	relate to the attribute, the a/v is added to a temporary list.  
        ( Note, if it fails 1 or more rules, or is not matched, then the
          a/v pair will *NOT* be transferred to the temporary list. )

     o  When all the reply vps have been checked, the original proxy reply
        vps are freed and the temporary list ( containing only those a/v
        that passed the rules ) becomes the new proxy reply vps.

     o  The module then returns UPDATED and the rest of the authorize block
        is called as usual.

---
Please send corrections/input/comments/flames to <cparker@starnetusa.net>