"Scott Bartlett" <[EMAIL PROTECTED]> wrote: > In FR 0.8, the file /docs/aaa.txt describes 'authorization' and > 'authentication' from FreeRadius' point of view and process. > > My own general (i.e. non-FreeRadius) understanding of these phrases (in > non-technical terms), as applied to any generic aaa system, is: > > Authenticate: proving the user is who they say they are. > Authorization: setting limits on what the user can and cannot do.
This comes up again and again. My inclination is say "go write your own radius server, and you'll see what's missing from yuor ad-hoc definitions" > Indeed, to pick a definition out of the air, > http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-10.txt > defines these words thus: > > Authentication > The act of verifying a claimed identity, in the form of a pre- > existing label from a mutually known name space, as the > originator of a message (message authentication) or as the > end-point of a channel (entity authentication). > > Authorization > The act of determining if a particular right, such as access > to some resource, can be granted to the presenter of a > particular credential. Agreed 100%. Question: How do you determine how the server authenticates someone? Answer : You check which authentication method they are authorized to use. I think I'm going to write some long text in 'doc/aaa.txt', telling people that all of their analogies and ad-hoc models are wrong. The server is designed the way it is because it works. Not because it's perfect, as there's always room for improvements. But it works. > In the general sense above, for any kind of system requiring aaa, the > user would 'authenticate' first and then be 'authorized' to do stuff. Nonsense. RADIUS servers have been designed similarly to FreeRADIUS for almost 10 years now. Would you say that for 10 years, those administrators were deluding themselves, and the servers really didn't work, because you didn't agree with the design? > There might be a bit of twiddling at a lower level unseen by the masses, > but this is the essence of the procedure (then followed of course by > 'accounting'). Again, nonsense. Design a RADIUS server, and then see what stages are required. If you're going to do a pre-authentication step of discovering which authentication method to use, then (for historical reasons, and because it costs next to nothing), you might as well assume they're going to be authenticated, and collect a set of reply attributes, too. Pushing the authorization step to AFTER authentication gains little. But note that in 0.8 and above, there's a post-authentication stage, in which anyone can do the extra post-authentication work that they desire. > For example, it says: "Authorization is a process of obtaining > information about the user from external source (file, database or > LDAP), and checking that the information in request is enough to > authenticate user. It does more than that. See the 'users' file. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
