[RADIATOR] matching based on one value of an attribute multiple times in request

[Tuure Vartiainen]

Hi,

> On 13 Jul 2017, at 15.56, Hartmaier Alexander <alexander.hartmaier at t-systems.at> wrote:
> 
> On 2017-07-13 14:19, Tuure Vartiainen wrote:
>> 
>> 
>>> On 13 Jul 2017, at 13.59, Hartmaier Alexander <alexander.hartmaier at t-systems.at> wrote:
>>> 
>>> I'm trying to build a solution to authorize users to log into devices
>>> based on their group membership in our NMS.
>>> 
>>> We use ClientListSQL to generate the Client config blocks and I've used
>>> the OSC-Authorize-Group attribute for add the group id's to the request
>>> attributes like:
>>> 
>>> OSC-Authorize-Group-123,OSC-Authorize-Group=456
>>> 
>> should the line above be "OSC-Authorize-Group=123,OSC-Authorize-Group=456"?
> Yes, sorry for the typo!
>> 
>> So OSC-Authorize-Group attributes define group ids which are allowed to login
>> to that device?
> It's added metadata for the request which includes all groups the device
> is member of.
>> 
>>> A Handler for example matches on OSC-Authorize-Group=123, which works as
>>> long as the device is only member of this single group but not if in
>>> multiple like in the above example.
>>> 
>> How is mapping to user groups done within a handler?
>> 
>> One option could be DynamicCheck which can be used for implementing a group check?
>> 
>> http://www.open.com.au/radiator/ref/DynamicCheck.html#DynamicCheck
> One handler per group, the AuthBy SQL only includes users authorized for
> that group of devices.
> The goal is to allow everybody in our team to modify the group
> membership through our NMS without any knowledge of Radiator or config
> change there.
> 
> <Handler Client-Identifier=radius-proxy-1, OSC-Authorize-Group=123>
> 

here’s a bit awkward way to configure a similar kind of a setup but 
by using only a one handler and DynamicCheck:

# 1. A pseudo attribute containing allowed groups is added in Client stanza
# 2. An extra AuthBy FILE with DEFAULT user is used to bind the pseudo attribute to GroupList check item
# 3. Actual AuthBy SQL is used for a group membership query and authentication

# Some client
<Client 10.10.10.10>
    ...

    # Allow users belonging to groups 123 and 234
    AddToRequest OSC-Authorize-Group="123 234"
</Client>

# AuthBy FILE for GroupList check item
<AuthBy FILE>
    Identifier AuthBy-FILE-Group-Check

    Filename %D/users-groups
</AuthBy>

# users-groups file contains a following line:
#
DEFAULT Auth-Type=AuthBy-SQL,GroupList=%{OSC-Authorize-Group}
#
# Auth-Type defines a next AuthBy to run and check items following 
# will be given as extra check items to that AuthBy

# AuthBy SQL doing group membership query and actual authentication
<AuthBy SQL>
    Identifier AuthBy-SQL

    ...

    DynamicCheck GroupList
    NoDefault
    # Define a group membership SQL query
    GroupMembershipQuery SELECT id FROM usergroups WHERE group=? AND user=?
    # group’s name
    GroupMembershipQueryParam %1
    # username
    GroupMembershipQueryParam %0
</AuthBy>

# a default Handler
<Handler>
    Identifier Default-Handler

    # Run AuthBy FILE called 'AuthBy-FILE'
    AuthBy AuthBy-FILE

    ...
</Handler>


BR
-- 
Tuure Vartiainen <vartiait at 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.