Re: Can RADIUS attributes pass through to Apache?

[Mark Lavi]

Hello everyone, This is a follow up on my quest for mod_auth_radius.c Apache module to pass on any additional attributes in an accept-access RADIUS packet. Alan asked that I review my proposal (pass the attributes down to the user's session via the HTTP "Pragma" header field) with Apache folks. I found, joined, and inquired with the [EMAIL PROTECTED] mailing list. I'm sharing the responses...see below. Alan DeKok wrote: "Mark Lavi" <[EMAIL PROTECTED]> wrote: The only mechanism I could find was in the HTTP 1.1 RFC, Chapter 14: Header Field Definitions, Section 14.32 Pragma at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32. Basically, the "Pragma" header is part of the HTTP response-header. Normally, it's used for a HTTP 1.0 backwards compatible manner to classify no-caching. But it is allowed to be used as any token_key=value response. I'd talk to some Apache people before deciding on that. It may work, but they should have more insight as to whether or not it's a good idea. I am keeping the respondent anonymous since I didn't ask if she/he wanted to be known. You could find this exchange on the mailing list archive, I'd imagine. On 5/8/03: Hi Mark, Interesting problem.  Your proposal seems reasonable provided you take care to either use a unique token name or re-use a commonly used token name.  Better, provide a config toggle to the Apache module to map RADIUS attributes to output pragma tokens.  Thus the user can always avoid a conflict.  Personally, I have never had any qualms about defining custom HTTP entity headers as allowed by the protocol. [snip] ...the issue is about the same as keeping user attributes from LDAP in a web session. I followed up and asked for some more details on an implementation and issues. On 5/9/03: Creating new headers or HTTP pragmas is OK as long as the client will do something with them.  When I did that, I was writing a back end system as a web service of sorts and found it convenient to include a bit of status data in the headers.  The middle tier was using the data to generate the ultimate output to the browser. I followed up with one more inquiry, and here's the response from the same individual. On 5/24/03: >In my case, there's no need to return the information - it is used inside the server-side context of >the user's session as the page is served to the client. So no need for cookies. Sounds like HTTP headers are the way to go, then, because most HTTP client libs give you a chance to read the headers before acting on the reponse body. ...but the issue is about the same as keeping user attributes from LDAP in a web session. Absolutely - what have you encountered for a solution to deliver (all of) the (entry's) LDAP attributes down to a web session? I think everything I said before applies.  You need only to serialize the LDAP data into a string, which you then encrypt and send as a single cookie "value".  The encrypted data should probably be less than 4KB, however.  This isn't a difficult constraint for most user profile data. If you want to keep larger objects around, you'll need a session data structure (w/ idle timeouts and corresponding cleanups).  I am still surprised no one has written a mod_session, but there it is. So there it is, I only got one person on the mailing list to respond, but nobody else said that our exchange wasn't proper or possible as we replied to each other. I believe that this corroborates the proposal as a sound way to proceed with HTTP Pragma headers. Alan, do you think this is sufficient? Thanks, -- --Mark o Atarex Communications: Web, Software, and Network Development /\/ Public key attachment for secure e-mail enclosed. // mailto:[EMAIL PROTECTED] || http://www.atarex.com

smime.p7s
Description: S/MIME Cryptographic Signature