Rudder plugins » Authentication backends

Some issues with the RADIUS Authentication backend:

- Currently the radius plugin uses some strange code for the Radius-Challenge part of the authentication process, and mentions SecurID, which is the RSA Token's authentication name, but RADIUS is not limited to RSA SecurID, but can be used to ask any kind of Questions the User has to provide a reaction to (hence challenge-response).

The first recommentadion is to get rid of mentioning "SecurID" from the code and if possible, make the first "Password" Prompt configurable, as the first secret could be anything, like a passphrase or a PIN, depending on what the first authentication step is.

- Most of the RADIUS Servers determine what authentication policy to use by the Client IP and/or the NAS-Identifier sent by the Client. This can allow to provide different auth methods by different RADIUS Clients originating from the same IP (even if the shared secret must be configured per originating IP of the Client).

The second recommendation is to provide a way (possibly via config file) to provide an optional value that will be sent as the "NAS-Identifier" attribute in the request.

Ref: https://tools.ietf.org/html/rfc2865#page-52

There is also other problem related to accepted access/response:

the radius plugin
has a cache for creds
anyway to disable that as it breaks OTP flows with Radius

It may be linked to:

- https://github.com/coova/jradius/issues/6
How to deal with the Access-challenge response?

- Or again: https://github.com/dodok1/cas/commit/29012f53bffb59cd25a83b27f0a14493efa64106