[RADIATOR] New features and changes in the next Radiator release

[Heikki Vatiainen]

On 06/18/2015 01:01 PM, Hartmaier Alexander wrote:

> Especially the work on sharing state between instances, we had problems
> with tacacs sessions from Cisco WLCs that authorize on a different
> server than the authentication happened which lead to non-working user
> rights.

Thanks for your comments. Does WLC do this when it has been configured
with multiple TACACS+ servers? That is, it does not try to use the same
server for all requests that belong to the user's session even if that
server is responding?

I'll make a note that this is one case where state sharing would be
needed for TACACS+.

> Regarding logging I'd love to see support for noSQL databases and
> messages queues like RabbitMQ and Elasticsearch which can be used as log
> target.

I would be interested to hear your and others' views about how to work
with different noSQL DBs and how they should be used with Radiator.

For example, there has been interest in Apache Cassandra for AuthBy CQL,
AuthLog CQL, session database etc.

With SQL we can use DBI to cover all the SQL databases. With noSQL it
seems each noSQL server needs its own interface. Or in other words, if
support for them is done one by one, which noSQL servers should be
supported first? For example MongoDB has good Perl support and is widely
used, but CQL seems to be a good, maybe better, match for this type of
application. Amazon Dynamo DB is, of course, restricted to AWS (and has
been used by us in one custom setup).

What comes to Elasticsearch, would using Logstash to read the files
while they are generated do the trick, at least for now?

About message queues, are you thinking about RabbitMQ, or the other MQs,
for logging only? I mentioned control plane in my previous message, but
we are also thinking about data plane to have something to distribute
requests between different instances. Pushing logs in a MQ could also be
done too.

Using both control and data plane is interesting because it allows for
more automatic and easier set up of multiple instances as opposed to
creating configuration files manually. A queue can be monitored to see
if the instances are starting to have problems processing all the
requests. If this happens, the queue management can log the problem or
start additional instances. Other useful features include log routing,
as you mentioned, maybe as a control plane service too.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.