Re: Can RADIUS attributes pass through to Apache?

[Mark Lavi]

Alan DeKok wrote:

Mark Lavi <[EMAIL PROTECTED]> wrote:
 

So long as the list of RADIUS attributes don't get sent out in the
HTTP response. That's my biggest worry with the use of HTTP headers,
and with Apache.
     

I'm not sure what response you mean, the web browser/client's response 
to the HTTP headers upon the next HTTP request back to the web server?
   

The response from the web server to the browser CANNOT contain any
RADIUS attributes.
Ah, if we are talking about the standard RADIUS attributes, then yes - 
that should not go down to the browser via HTTP headers. However, I am 
talking about the extended (potentially vendor specific) attributes 
included into the access-accept packet that are currently discarded in 
mod_auth_radius.

You bring up a good point: there could be information communicated down 
to the browser that could be utilized to undermind security, abuse a 
system, etc. So that suggests that sending down all extended attributes, 
by default, would be a bad design.

So if mod_auth_radius could be configured to specify what attributes 
could be "public" and passed down, that would solve the problem. 
Attributes are promoted as public information could be utilitzed. My 
example would be to enable a "group=Engineering" attribute to utilized 
in the server side environment.

By passing the attributes, they can be used in the server side environment (CGI/PHP/etc.) and that's the value I am after.
   

 Where are the attributes passed to, inside of the server?
a) environment variables: no, they stick around from request to request
b) HTTP headers: no, they get sent back to the browser
c) ?
 

Own suggested ENVIRONMENT  variables, too and we had already discussed 
this. Unless ENVIRONMENT variables can be made live for only the 
connection's lifecycle, this would not be a good solution.

Option C would be inter-module passing or another internal data 
structure used in the server (sounds painful). I feel that option B, 
with specific attributes enabled, would be a workable solution.

--
--Mark
o  Atarex Communications: Web, Software, and Network Development
/\/ Public key attachment for secure e-mail enclosed.
//  mailto:[EMAIL PROTECTED] || http://www.atarex.com


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html