(RADIATOR) When dealing with a fair bit of logic in the authentification procedure

[Matthew Lohier]

Hi Hugh,

Hooks by themselves were not providing enough flexibility to handle all the
logic, but associated with AuthBy GROUP and AuthBy INTERNAL they became very
powerful and effective. So they did the job perfectly! Thanks.

I still have a quick question:

Suppose I have the following clauses with lookUT a AuthBy LDAP2 clause.
<AuthBy GROUP>
	AuthByPolicy others
	AuthBy lookupUT
	<AuthBy INTERNAL>
		AuthHook file:"%D/checkUT.pl"
	</Authby>
</AuthBy>

The lookUT (LDAP) clause gets executed, an entry may have been found in the
LDAP directory, and may be returned.
Because of the policy the AuthHook gets executed. 
How can I quickly and generically check that the reply message contains an
LDAP entry (or that no entries were found)? 
I currently look for a "known" attribute in the reply message (that the
lookUT clause would have put in the reply), and if it's not there I conclude
that no entry was found. But it's not generic, and error-prone.

Let me know if there's a better way.

Thanks a lot / Matt



-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: Thursday, 4 August 2005 11:21 AM
To: Matthew Lohier
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) When dealing with a fair bit of logic in the
authentification procedure


Hello Matt -

I suggest you consider using a hook to implement your logic (probably  
a PostAuthHook).

See the examples in "goodies/hooks.txt".

regards

Hugh


On 4 Aug 2005, at 10:31, Matthew Lohier wrote:

> Hi Hugh,
>
>
>
> I'm running Radiator-3.13 on linux, and I'm in the process of  
> implementing an authentification procedure with Radiator. Our  
> procedure -or procedures I must say- are quite complex and involve  
> quite a lot of logic.
>
> They take:
>
> -          2 LDAP queries,
>
> -          6 to 8 logical expressions ( if() ) mostly based on the  
> returned attributes from the ldap queries.
>
>
>
> I have so far developed a prototype using AuthBy EXTERNAL based on  
> a perl script that handle the logic and queries the LDAP servers.  
> It's working well (using radpwtst, single-shot test case) but I'm  
> not sure how good it's going to perform in a real environment.
>
>
>
> I have read the bit about Fork config parameter. I will experience  
> both configurations.
>
>
>
> Is there any other alternative than AuthBy EXTERNAL that could  
> handle all the logic we need. Of course AuthBy LDAP2 works well to  
> perform a LDAP query but then it does not give me the necessary  
> logic I think.
>
>
>
> I've included a pseudo-code to give you some indication on what I'm  
> trying to achieve.
>
>
>
> Procedure:
>
> The Access-Request issued to Radius includes parm1, parm2 and param3.
>
> 1/ LDAP1 query based on param1
>
> 2/ If no entry Access-Reject is returned.
>
> 3/ If reply1-attribute1 == 3, we need to match reply1-attribute2  
> with param2.
>
> 4/ If the matching fails Access-Reject is returned.
>
> 5/ LDAP2 query
>
> 6/ If no entry a pre-configured action is returned (Access-Accept  
> or Access-Reject).
>
> 7/ If entry is found, reply2-attribute1 is tested
>
> 8/ If reply2-attribute1 == 1 Accept-Reject is returned.
>
> 9/ If reply1-attribute1 == 2, regular expression must match with parm3
>
> 10/ If they don't match, Access-Reject is returned.
>
> 11/ Access-Accept is returned with other reply-attributes
>
>
>
> I guess I'd like to be sure that AuthBy EXTERNAL is the way to go  
> in this case, or otherwise be given some new directions.
>
>
>
> Thanks for your reply, best regards / Matt
>



--
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.