(RADIATOR) Radiator setup for dual authentication

[Jonathan K]

Hi,

We've got a bit of a tricky setup here which we've solved by using a 
ReplyHook but i'd like to run it by the list to see if it's the best 
method for what we're trying to achieve.

We run a managed platform that handles authentication via radiator and a 
mysql backend, we have a new customer coming online who would like to 
have control over their user base via proxied RADIUS requests. This is 
all good, but because of the method that the client is using to 
synchronise their data from us, we need to also authenticate the user 
using our normal method (local sql database). The flow we are looking 
for is as follows:

1. Receive Access-Request from client
2. Proxy request to downstream RADIUS server
3a. If downstream server responds with Access-Reject, send Access-Reject 
to client
3b. If downstream server responds with Access-Accept, auth from local 
sql server
4a. If local auth fails, send Access-Reject to client
4b. If local auth succeeds, send Access-Accept to client


I thought this would be a simple matter of having a handler with 
ContinueWhileAccept and two consecutive AuthBy's but what we've found 
when using this method is that Radiator sends duplicate packets back to 
the requesting NAS (in our testing, radpwtst). While radpwtst only 
receives the one packet (tcpdump shows that two are being sent), we're 
not sure (and don't want to test) how a NAS will respond to this, or 
what will happen if the wrong AuthBy sends the first reply, which 
doesn't have the correct info.

Basically this is what happens:

1. Radiator gets Access-Request
2. First AuthBy (RADIUS) executes and proxies request to remote server
3. Second AuthBy (SQL) executes
4. Second AuthBy succeeds and sends Access-Accept back to client
5. Radiator receives reply from remote server and proxies Access-Accept 
back to client

We've managed to get the required behaviour by setting the Synchronous 
flag but this isn't acceptable for our installation, we've also 
experimented with  the Fork and Synchronous flags together which 
produces the same duplicate reply problem.

What we've done is written an external hook based on 
"AllocateIPAddressOnReplyFromProxy" which evaluates the remote servers 
response and goes off and runs our local AuthBy then allocates the IP in 
the normal way or rejects the client. It does what we want.

We have:

<Handler /matches_for_customer/>
	AuthByPolicy    ContinueWhileReject
	AuthBy          CustomerAuth
</Handler>

<AuthBy RADIUS>
	Identifier CustomerAuth
	<Host 111.111.111.111>
		secret	foo
	</Host>
	# Reply hook evaluates response from remote server
	# if success then points to our regular AuthBy SQL
	# then assigns address
	ReplyHook file:"%D/customer.hook"
</AuthBy>


So my question is, is this an optimal way of dealing with this? Can 
anyone see any room for improvement in our model? This customer has 
about 15,000 clients and we are looking at this solution for another 
client with a number of clients in the 1000's and need to know it scales.

Thanks in advance.

Jon

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.