freeradius-proxy with Rlm_cache

[Phil Mayers]

On 20/02/13 08:38, Dominique Frise wrote:
> Hi,
>
> We would like to configure a freeradius proxy-server v. 2.2.0 under
> RHEL6 with users caching.
>
> The scenario we would like to achieve is the following:
>
> 1. client sends username/OTP to freeradius-proxy that relays to central
> radius server.
> Central radius server accepts and replies to freeradius-proxy that
> relays to client.
>
> 2. client sends same username/OTP within TTL to freeradius-proxy that
> accepts and replies to client.
>
> This should be possible using Rlm_cache module but we did not find a
> proper how-to for configuring this.

Can you show a debug ("radiusd -X") of an auth request? This will make 
it more obvious what attributes you need to have as key/value.

Also, this will probably only work if your OTP is simple PAP-like i.e. 
request/accept. It probably won't work if Access-Challenge or any 
challenge/response is involved.

But, for example, if your request looked like this:

User-Name = foo
User-Password = bar
OTP-Password = 123456

...then you'd want an rlm_cache config like this:

cache otpcache {
   # note - we need to escape the key values
   # otherwise the client can perform injection/overlap
   # attacks by modifying their username
   key = 
"%{urlquote:%{User-Name}}/%{urlquote:%{User-Password}}/%{urlquote:%{OTP-Password}}"
   ttl = 60
}

...and then:

authorize {
   # first, just check the cache, don't
   # create entries or set reply attrs
   update control {
     Cache-Status-Only = yes
   }
   otpcache

   # future cache lookups here, and in post-auth,
   # should be normal ones
   update control {
     Cache-Status-Only !* ANY
   }

   if (ok) {
     # entry found in cache; set auth type to accept
     # and call cache again to get reply attrs
     update control {
       Auth-Type := Accept
     }
     otpcache
     ok
   }

   ...
}
post-auth {
   # first, delete any existing cache entries
   update control {
     Cache-TTL = 0
   }
   otpcache

   # clear that variable
   update control {
     Cache-TTL !* ANY
   }

   # now cache the reply
   otpcache
}

It's a bit awkward TBH; I kind of wish modules could have "named 
methods" e.g. "cache.{check,get,set,expire}" but you can wrap it all in 
a policy.conf if you want readability.