Thanks for the suggestions; the key hint you and Hugh gave me is that
both DUO and RADIUS always return IGNORE (or REJECT in certain failure
modes), never ACCEPT. What I came up with looks like a combination of
your suggestions:
<AuthBy GROUP>
AuthByPolicy ContinueWhileAccept
<AuthBy GROUP>
AuthByPolicy ContinueUntilAccept
AuthBy LDAP2
AuthBy RADIUS
</AuthBy>
AuthBy DUO
</AuthBy>
Since RADIUS can never return ACCEPT, DUO is only invoked if LDAP2
returns ACCEPT. The final (immediate) auth result will always be either
IGNORE or REJECT. An eventual ACCEPT result will come from either DUO
or RADIUS once a response comes from either handler. This should give me
the desired semantics.
On 11/8/2013 4:39 PM, Heikki Vatiainen wrote:
> Hello Christopher,
>
> here's my take:
>
> <Handler>
> AuthByPolicy ContinueWhileReject
> <AuthBy GROUP>
> AuthByPolicy ContinueWhileAccept
> AuthBy LDAP2
> AuthBy DUO
> # DUO is async, returns IGNORE, just like RADIUS
> </AuthBy>
>
> AuthBy RADIUS
> </Handler>
>
> If LDAP happens to be down or returns an error, AuthBy LDAP2 will return
> IGNORE and GROUP will not continue. This might be a good thing too?
>
> Thanks,
> Heikki
>
>
> On 11/07/2013 08:31 PM, Christopher Bongaarts wrote:
>> That would seem to yield the effective logic:
>>
>> AuthBy LDAP2
>> if result = ACCEPT
>> then
>> AuthBy DUO
>> if result != ACCEPT
>> then
>> AuthBy RADIUS
>> endif
>> endif
>>
>> which is not what I want - either DUO or RADIUS should be invoked, never
>> both; which one is invoked is determined by the result of LDAP2.
>>
>> This is close:
>>
>> <AuthBy GROUP>
>> AuthByPolicy ContinueUntilAccept
>> <AuthBy GROUP>
>> AuthByPolicy ContinueWhileAccept
>> AuthBy LDAP2
>> AuthBy DUO
>> </AuthBy>
>> AuthBy RADIUS
>> </AuthBy>
>>
>> but will invoke RADIUS unnecessarily if LDAP2 returns ACCEPT but DUO
>> returns REJECT or IGNORE. Security-wise this is OK (it is not possible
>> for this RADIUS to succeed if LDAP2 succeeded) but does put an extra
>> load on the proxied RADIUS service.
>>
>> On 11/6/2013 4:24 PM, Hugh Irvine wrote:
>>> Hello Christopher -
>>>
>>> Something like this:
>>>
>>> <AuthBy GROUP>
>>> AuthByPolicy ContinueWhileAccept
>>> AuthBy LDAP2
>>> <AuthBy GROUP>
>>> AuthByPolicy ContinueUntilAccept
>>> AuthBy DUO
>>> AuthBy RADIUS
>>> </AuthBy>
>>> </AuthBy>
>>>
>>> regards
>>>
>>> Hugh
>>>
>>>
>>> On 7 Nov 2013, at 08:51, Christopher Bongaarts <c...@umn.edu> wrote:
>>>
>>>> I have a need to handle multiple authentication methods which returns
>>>> something like this:
>>>>
>>>> AuthBy LDAP2
>>>> if result = ACCEPT
>>>> then
>>>> AuthBy DUO
>>>> else
>>>> AuthBy RADIUS
>>>>
>>>> with the ultimate authentication result coming from either the DUO or
>>>> RADIUS module. I tried to figure out a way to arrange some combination
>>>> of AuthBy GROUP and AuthByPolicy to make this fly but I can't seem to
>>>> figure out a way to make it work. Any suggestions?
>>>>
>>>> --
>>>> %% Christopher A. Bongaarts %% c...@umn.edu %%
>>>> %% OIT - Identity Management %% http://umn.edu/~cab %%
>>>> %% University of Minnesota %% +1 (612) 625-1809 %%
>>>>
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator@open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>> --
>>>
>>> Hugh Irvine
>>> h...@open.com.au
>>>
>>> Radiator: the most portable, flexible and configurable RADIUS server
>>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>>> DIAMETER etc.
>>> Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
>>>
>>
>
--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
