Concepts of radiusd

In this work the C++-Classes to manage the radiuspackets are in the center of interest. So they are reused in the clients and the radiusd. So we can implement many policies.

Merit

In the Merit Authentication, Authorization and Accounting Server (formerly Radius) are many Interfaces to other Authentication Schems, so that a special Interface (aatv) is neseccary.

That meens, there is a heterogen distributed Userdatabase.

My Concept

I think that a (logical) central Database (which may be physical distributed) for all services would be more easy to manage.

All Authentication-Systems like radius, Tacacs, and login/ftpd/... have to ask the Database.

So the passwd-Map of the NIS/YP can be replaced by the central Usermanagement database.

In the Ascend/Livingston-Implementation, there is a Default-Entry, which is taken, if no other userprofile is found.
By W-4 there is the policy that people have a free E-Mail-address (that means, the have a E-Mailaccount/login) but are not dail-in-customers.

The users-File in the other implementations are like an logic-System: If you have this Check-attributs, you get these Reply-Attributes.

Some Reply-Attributes may be nonterminal. So we can have something like groups or common Attribut for an NAS or Service.

The Reply-Attributs can be regarded as a Capability in object-oriented Operationsystems like HYDRA.