[RADIATOR] AuthByPolicy Question - "anything else"
Joe Hughes
joeyconcrete at gmail.com
Fri Jan 1 17:49:12 CST 2010
On Page 93 of the manual it describes an AuthByPolicy of 'anything else' -
does this literally mean a random string (e.g bleh), I'll explain.
I have a scenario whereby I have an AuthBy GROUP which contains an AuthBy
FILE and an AuthBy RADIUS.
The AuthBy FILE contains a list of users along with some user specific
attributes for 'authorisation' purposes, it does not contain any
authentication information (e.g. passwords).
The AuthBy RADIUS needs to do the actual authentication. I want the system
to grab the attributes from the file (if they exist) and then perform the
authentication against the AuthBy RADIUS - returning the Accept\Reject - and
any attributes that were in the file (if the user was accepted).
The important point is, not *every* user will need additional attributes so
they may not exist in the file, but they will on the external RADIUS server.
The external RADIUS server isnt capable of returning any user attributes -
literally accept\reject. I don't want to store passwords on this (radiator)
box for admin purposes, just attributes if necessary.
Sample config (some bits stripped);
<AuthBy GROUP>
AuthByPolicy bleh
<AuthBy FILE>
Filename %D/UserAttribs.txt
</AuthBy>
<AuthBy RADIUS>
Host test
Secret 22mxm12cCX
</AuthBy>
</AuthBy>
I have tried;
- ContinueWhileAccept - which works if *every* user exists in the
UserAttribs.txt file - but fails if they dont (because it generates a
REJECT)
- ContinueUntilAccept - which works but never actually authenticates against
the RADIUS server if the user definition exists (because it gets an initial
ACCEPT).
- AuthByPolicy bleh;
If the user exists :- it gets a ACCEPT at the AuthBy FILE *and* an ACCEPT at
the second AuthBy RADIUS - the AuthBy GROUP honours the 2nd ACCEPT along
with the attributes from the AuthBy FILE
If the user doesn't exist - it gets a REJECT at the AuthBy FILE but an
ACCEPT at the second AuthBy RADIUS - the AuthBy GROUP returns the ACCEPT but
with *no* FILE attributes
My question is; is my choice of "AuthByPolicy bleh" the best option for my
given scenario and is this is best way of approaching this?
Cheers
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20100101/137f117a/attachment.html
More information about the radiator
mailing list