In general there are three steps in processing of Access-Request:
- identify - authenticate - authorizeFirst you need to identify subscriber. In general you should consult subscriber database (backend). To minimize number of round-trips with subscriber database it will be better to return whole subscriber profile to AAA server. AAA server then can consider to proceed with authentication, grant access without authentication, deny access without authentication, or just pass the matter to proxy. This is what authorize section exactly does. Subscriber profile retrieved on this step is stored ad-hoc, usually in control and reply lists of the request.
To authenticate subscriber you need to check credentials it provides. This is what authenticate section does. Most of authentication modules use Cleartext-Password attribute from control list to check credentials against.
To authorize subscriber you should make a decision based on both subscriber profile and authentication result. This is what post-auth section does. Put your authorization policies in this section.
Edgar Fuß wrote:
A probably simple question I could not find explained in the FAQ or the Concepts section: Given that Authentication is proving who I am and Authorization is checking what I'm allowed to do, I naively would have expected a RADIUS server to first authenticate me an then check my authorization. Surely for a reason, what FreeRADIUS does is the other way round: first try all authorization modules and then use one authentication module. I hope I got this right. I would like to be pointed to a document explaining the rationale behind this. It's probably obvious to anyone familiar with the matter, but that doesn't include me. Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
smime.p7s
Description: S/MIME Cryptographic Signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
