General question about authentication/authorization

[Phil Mayers]

Florian Prester wrote:

>  >> so, AFAIK authorization is retreiving user-information from a source?

Yes, however see Alan's reply - his "yes" and my "no" are not as 
contradictory as they might seem (it's purely semantics). See below.

> ok, lets assume a user can authenticate because he/she supplys a valid 
> username/password e.g. using PAP. Now the user is authenticated.
> But I want to allow access to something not only if the user is 
> authenticated, but also if a given attribute is present in the users 
> ldap enty.
> How can I do that?

Well, if the user is REJECTed, regardless of what is put in the reply 
packet[1], as long as the NAS is sane then they won't get access to 
anything, so it should not matter if you put the attributes in but then 
reject them.

For example. Say you are using LDAP, and your NAS gives admin privs. 
based on the Class attribute in the Radius reply (unlikely, but it's a 
simple example):

dn: cn=username,dc=domain,dc=com
cn: username
radiusClass: Administrator
userPassword: APassWord

...and:

authorize {
   preprocess
   ldap
}
authenticate {
   Auth-Type LDAP {
     ldap
   }
}
post-auth {
   ippool
   somelogging
   Auth-Type REJECT {
     somerejectlogging
   }
}

The flow is:

  1. request comes in, User-Name==username
  2. authorize run
     i. preprocess run
     ii. ldap run
         * LDAP search done - entry found
         * Ldap-UserDn is set to entry DN
         * Class==Administrator is set
         * Auth-Type==LDAP is set
  3. authenticate run, Auth-Type LDAP subsection ONLY,
     * ldap module run - does LDAP simple bind to Ldap-UserDn with 
User-Password
     * if password OK - Accept
     * if password NO - Reject
  4. post-auth run
     * if Accept - run main body
       * ippool run
       * somelogging run
     * else if Reject - run Auth-Type REJECT subsection ONLY
       * somerejectlogging run

So if the user gives the wrong password, the Class attribute may[1] be 
added to the reply, but they'll still get a REJECT so does it matter? If 
they give the right password, they'll be accepted AND given the admin privs.

The only time it matters whether auth succeeds or rejects is when the 
attribute you're returning is a dynamic resource which you absolutely do 
not want to allocate for failed requests e.g. an IP assignment. If 
that's the case, then you'd need to do something in the post-auth 
section where you can differentiate between auth success and failure.

The only modules that implement post-auth handlers useful for such 
dynamic allocation purposes are exec, files, ippool, perl and policy. 
But I'm guessing it's a static thing and you can go with simple LDAP 
attributes, especially given that...

[1] In recent versions of FreeRadius (1.1.0 and up?) the server will 
automatically strip everything from a REJECT except EAP-Message, 
Message-Authenticator and Reply-Message (and Proxy-State). This is 
specified by the RFCs anyway. So in recent versions of the server, the 
Class attribute wouldn't even go to the NAS, so it truly doesn't matter 
if you add it then fail it. That's a recent change though.