rlm_perl question (was Re: General question about authentication/authorization)

[Phil Mayers]

George C. Kaplan wrote:
> Phil Mayers wrote:
>> Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set
>> Auth-Type based on the incoming requests e.g. the "mschap" modules sets
>> Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the
>> "chap" and "eap" modules. "pap" is a bit more complex and has changed in
>> CVS head.
>>
>> Generally, you should not set Auth-Type in the users file. It's a sign
>> you're doing something wrong. Perhaps if you told us what you're trying
>> to do?
> 
> I've been wondering about this, in relation to the rlm_perl module.  We
> see "Don't set Auth-Type in the users file" all over the place, but with
> rlm_perl, the %RAD_CHECK hash is read-only.  So if I'm using perl for
> authorization, I *have to* set the Auth-Type in the users file.

You shouldn't really ever have to set it AT ALL, EVER, though some of 
the fixes that make that a doable proposition are only in newer (CVS?) 
versions of FR - e.g. the reworking of the PAP module, optional setting 
of the Auth-Type on the ldap module, {algo} detection in the 
User-Password field, and so forth.

As far as I can tell, there are really 2 classes of FreeRadius module:

  1. Authentication algorithm modules - these do two things:
     * in authorize, examine the request for attributes indicating the 
request is using the algorithm they implement. If present, set Auth-Type 
to AUTHALGO.
     * in authenticate, get run by "Auth-Type AUTHALGO" conditionals, 
and execute the auth algorithm using the request data and any other data 
(e.g. check items added by other modules)

  2. Authorization modules that add data to config items (and other 
things as well, but mainly that)

There is a special case of the first which hand off "algorithms" to 
external sources - for example, the ldap and pam "authenticate" handler 
really implements PAP, but by doing something different (and it's 
further complicated by the fact that ldap is ALSO an authorization 
module AND it's authenticate function is dependent on configure items it 
adds at authorize time - specifically Ldap-UserDN)

The only case I can see where you need to Auth-Type is when you have a 
need for >1 copy of an authentication algorithm with different 
parameters e.g. for different services. This can typically be handled 
more cleanly IMHO with Autz-Type. So, for example:

modules {
   # shared modules - no state, irrelevant which service they answer
   chap {
     authtype = CHAP
   }
   # service 1 modules
   mschap mschap1 {
     # we'll to MS-CHAP internally
     authtype = MS-CHAP1
   }
   files files1 {
     userfile = ${confdir}/users1
   }

   # service 2 modules
   mschap mschap2 {
     # we'll call out to ntlm_auth DOMAIN1
     ntlm_auth = "/opt/samba_DOMAIN1/bin/ntlm_auth --args"
     authtype = MS-CHAP2
   }
   files files2 {
     userfile = ${confdir}/users2
   }

   # service 3 modules
   mschap mschap3 {
     # 2nd install of samba e.g. no interdomain trust between domains
     # so join both!
     ntlm_auth = "/opt/othersamba/bin/ntlm_auth --args"
     authtype = MS-CHAP3
   }
   files files3 {
     userfile = ${confdir}/users3
   }

}

authorize {
   preprocess
   files
   Autz-Type SERVICE1 {
     files1
     mschap1
     chap
   }
   Autz-Type SERVICE2 {
     files2
     mschap2
     chap
   }
   Autz-Type SERVICE3 {
     files3
     mschap3
     chap
   }
}
authenticate {
   Auth-Type CHAP {
     chap
   }
   Auth-Type MS-CHAP1 {
     mschap1
   }
   Auth-Type MS-CHAP2 {
     mschap2
   }
   Auth-Type MS-CHAP3 {
     mschap3
   }
}

/etc/raddb/users:

DEFAULT Huntgroup-Name=="service1", Autz-Type := "SERVICE1"

DEFAULT Huntgroup-Name=="service2", Autz-Type := "SERVICE2"

DEFAULT Huntgroup-Name=="service3", Autz-Type := "SERVICE3"

> 
> This isn't really a problem (since it all works the way I want), but it
> seems inconsistent, especially considering that other modules can modify
> the request or check items.  So, why were %RAD_CHECK and %RAD_REQUEST
> made read-only?
> 

I can't say specifically in that case. It does seem odd. But that still 
doesn't make setting Auth-Type any cleaner ;o)