Re: Can RADIUS attributes pass through to Apache?

[Mark Lavi]

Alan DeKok wrote:

"Mark Lavi" <[EMAIL PROTECTED]> wrote:
 

...For instance: user-name, class, connect-info, and vendor-specific attributes 
all might be information from the RADIUS server that could be further 
utilized by an application without relying on another data source.
   

 How?

Right now, a RADIUS authenticated user for a web server is a binary 
solution. This is fine for many situations: you are either authorized or 
not authorized.

However, it is common to have different "groups" in an authenticated 
population. Say, for instance, a department of an organization. Once you 
know that attribute (if it exists) for a person, you can say restict 
access to different resources on the web server. This is usually used 
for controlling directories of content. An example would be: 
group=Engineering can read and publish to the /engineering directory, 
but group=Engineering cannot read the /sales directory.

Being able to determine the group is crucial for permissions and most 
Apache server authenication modules that I have encountered support 
group attributes. See URL:
http://httpd.apache.org/docs/howto/auth.html#basicconfig

Groups are usually defined as a list of usernames in a file (an external 
source), but it is much more useful/secure/managable to have the group 
attribute provided by the authenticating resource.

The web application I am helping to design and RADIUS is the only 
authentication allowed in the environment I must work in. I hope it is 
now noted that the additional access-accept attributes could be useful 
in a web server environment.
   

 Sure, but what do you do with them?  Would anyone else do the same
things?
I would enable permissions for a group of an authenticated population to 
access certain areas of content, typically.

I believe that others would do the same since most Apache authentication 
modules provide the provision (although I will grant you, it is entirely 
optional to use it for authentication) for groups.

Finally, if the group (or any other RADIUS attribute) is exposed at a 
server environment variable, this would be a mechanism for any server 
side web application to leverage that information for conditional 
security based upon those attributes within a page of an application. 
(i.e.: show the executive group a link to some important report but do 
not show that link to engineering).

Hypothetical example, not any particular language, consider it 
pseudocode that could exist inside of a web server pasred page or 
application:

$attributes = $APACHE_SERVER_ENVIRONMENT["RADIUS_ATTRIBUTES"];
if ( index($attributes, "Engineering") > -1 )
{ print "<h1>Hello to everyone in Engineering</h1>\n"; }
# or use your favorite regular expression search
So it is quite useful to leverage that information, whatever it might 
be, from the authenticating resource.

I will agree that this is site/application specific and optional.  I 
will not fault you on saying that pragmattically this is not an intended 
use of RADIUS or that this cannot be a priority over producing more 
documentation or getting 0.81 out of beta.

But I trying to convey two notions to justify the expansion of 
mod_auth_radius.c:

1. Groups are an important attribute utilized in many situations and 
environments.
  They are enabled in even the most basic Apache authentication modules.
  We can witness a fork which, amongst other things, attempts an 
implementation of groups.
2. The ability to leverage RADIUS attributes in a web server environment
   extends the utility of RADIUS, whatever those attributes may be.
   Discarding those attributes reduces RADIUS' utility.
   It also forces the use of a third party resource when such 
attributes are required,
   adding data and security overhead, management, and exposure when RADIUS
   could be utilized.

One can see that groups are just a special case/instance of the RADIUS 
attributes, reducing this to only one agument.

Re: the other deviation/fork and adding it to the Other Resources section:

 Yeah.  He spent a year making changes, and finally mailed me about
it last November.  I responded, and asked to merge our efforts, so
 

 <shrug>  Sure.  But it would validate the approach of forking the
code base, making incompatible changes, and never feeding patches or
fixes back upstream to the original author.
I understand why you would take that policy stance: I would prefer a 
unified mod_auth_radius.c, too! One must understand what the motivation 
is for each fork.

That is SO location-specific that I doubt it should go into the
default source for the module.
 

I feel that groups are a more generic requirement in authentication (and 
less site specific, although the above implementation is fairly 
specific) which we can witness in every modern operating system and all 
(up until now :~) Apache authentication modules I've encountered.

Not having the "escape mechanism" or back channel to expose the RADIUS 
attributes to the web server reduces the full utility of this module and 
the RADIUS server.

I will understand and respect your decisions, I'm thankful to you and 
the freeradius community for this work. I hope this discussion is 
constructive to promote the further utility of RADIUS with web applications.

Thanks again for your time,
--Mark
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html