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

[Matthew Lohier]

Thanks Hugh for the trick, it works well and makes the Hook's code a bit
more generic.

Cheers / Matt

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: Friday, 12 August 2005 11:39 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 -

What I have done in the past is use an AddToReply in the AuthBy LDAP2  
clause.

The AddToReply will only happen if the clause accepts, so you can  
easily check it.

I used the "Reply-Message" attribute:

         <AuthBy LDAP2>
                 .....
                 AddToReply Reply-Message = Authentication succeeded
         </AuthBy>

then the hook checks the Reply-Message

         my $message = $rp->get_attr('Reply-Message');

         if ($message =~ 'succeed')
         {
                 .....
         }

regards

Hugh


On 12 Aug 2005, at 11:19, Matthew Lohier wrote:

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


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.





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