[RADIATOR] AuthBy FILE + IfNotExist and/or maintaining Access response

[Nathan Anderson]

On 10/22/09, Hugh Irvine <hugh at open.com.au> wrote:

> Hello Nathan -
>
> I would suggest a ClientHook to add an attribute to the request,  
> identifying the type of device - you could use OSC-Client-Identifier  
> for example.
>
> Then set up different Handlers for each type of device:

[snip]

Hello Hugh,

Thanks for the response.

As I mentioned in another reply, I considered using Handlers (which I should be able to define without ClientHook and limit to 2 total Handlers, a Default and a DELL, given that I know how to identify the special-case devices, the Dells, and the others work fine with a unified configuration), but the issue I ended up running into is that for each Handler, three AuthBys need to be consulted BEFORE the reply attribute rewrite is performed, and a given user/pass will only have a match in one out of the three AuthBy sources.  For the Default/non-DELL one, this isn't a problem; I just use AuthByPolicy ContinueUntilAccept.  But for the DELL Handler, I can't do that because before I reach the end of execution in the Handler, I need to perform the Service-Type reply attribute replacement as the *very last action*, and because there is no way to preserve an Access-Accept if one of the earlier AuthBys accepts it and a later one rejects it, unless the user/pass match happens in the very last AuthBy, the client will get back Access-Reject even for valid matches for AuthBys other than the very last one in the Handler.  (I hope that made sense...)

Would it have worked to combine your two suggestions together, and use AuthBy GROUP within the Handler like this?:

<Handler OSC-Client-Identifier = DELL>
  <AuthBy GROUP>
    AuthByPolicy ContinueUntilAccept

    <AuthBy LDAP2> ... </AuthBy>
    <AuthBy LDAP2> ... </AuthBy>
    <AuthBy FILE> ... </AuthBy>
  </AuthBy>

  StripFromReply Service-Type
  AddToReply Service-Type=Administrative-User
</Handler>

In the end, I didn't get to test this out because I came up with another solution.  I was able to patch Radiator to do one of the two things I originally suggested I could use to fix the problem.  One proposal was to lock-in an Access-Accept once one is obtained in an AuthBy chain.  I didn't work on that, though it might be a handy tool to have in my belt in the future.  What I did do was create a simple one-line patch to AuthGeneric.pm that checks to see if a reply attribute with the same name already exists in the constructed reply packet before adding another one.  It's quick-and-dirty, but it works and it solved my problem.  I now have one streamlined default Handler or Realm defined that works with all of my equipment.

I have attached a patch to AuthGeneric.pm with my change, and I also added a toggle to enable or disable the new behavior.  Since AuthFILE inherits from AuthGeneric, you can toggle this feature on inside the <AuthBy FILE> part of your config.  This probably isn't ready for prime-time, so in its current state you probably don't want to merge it in with the main Radiator source tree. ;)  I'm also not married to the name I came up with for the feature toggle.  But perhaps it would be useful to someone else regardless, so I'm posting it here (maybe a candidate for the 'goodies' directory?).

Thanks,

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AddReplyAttributeIfNotExist-4.4.patch
Type: application/octet-stream
Size: 1215 bytes
Desc: AddReplyAttributeIfNotExist-4.4.patch
Url : http://www.open.com.au/pipermail/radiator/attachments/20091026/3ef04160/attachment.obj