On 9 Sep 2012, at 05:27, Thomas Glanzmann <tho...@glanzmann.de> wrote:
> Hello Arran,
>
>> What is the server missing as of 2.2.0 that requires the use of rlm_perl?
>
> I'm not aware of the FreeRadius internals but you can simply look at the
> FreeRadius Module rlm_smsotp. This is what happens.
>
> - User authenticates with PAP
> - The server answer will be of access challenge type and
> includes two additional fields:
>
> - State: Random number (FreeRadius has to keep it an
> associate that with the generated otp)
>
> - Prompt
>
> At the same time a otp random number is also saved and
> associated with the state and the user and sent to the user
> for example using a SMS but it could of course use any other
> otp method for example with preshared key.
>
> - The client answeres and provide the state and otp in the
> 'passowrd' field. The server than has to verify:
>
> - Is the state corresponding to user name and otp?
>
> - Is the request still valid (timeout)?
>
> That's basically it.
Ok
>
>> On the surface it seems all you're missing is random string generation?
>
> If it can't do that, than yes for the state and the otp value.
>
>> With 3.0 you can define policies which have 'methods' that map to the
>> different sections of the server, so you could write the whole thing
>> as a virtual module.
>
> If you walk me through it, I would like to try that.
Just name your policies using <virtual_module>.<section> {}, then use instances
of the always module to set the return code :)
For storing the state take a look at the new rlm_cache module, it'd be perfect
for this (so long as you don't need state to be shared between servers, or
persist after restarts). I'll look at adding a special xlat method to generate
random strings.
-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
