[Users] users acl

[Bogdan-Andrei Iancu]

Hi Cesc,

that's a good thinking - let;s learn from history.

if we assign a group ID, the group IDs a user belongs to will be kept in 
a separate table (like grp now) and all IDs will be loaded together in 
avps with same ID/name; once loaded, only checking the AVP values will 
be enough for ACL membership.

In this case we will not be able to load the ACL at auth time (at least 
not from DB) and a separate query will be needed. But is a good 
compromise comparing with current approach.

Also I still consider keeping a table with group Id definitions names -> 
ID for an easy manipulation.

regards,
Bogdan

PS: what I really like to this possible approach is that nothing more 
must be done :) - avpops will do it

Cesc wrote:

>Hi,
>
>Why stay with limiting stuff?
>This 32 limit I have already seen with the number of available flags
>... and also with the sip_header_types defined (ever tried to define a
>new HDR_xxx type? there is no space available! ) ... why don't you try
>to find a way so that all this limitations are overcome?
>I know it is faster a bitmap check ... but maybe assigning plain index
>numbers and checking for equality would be almost as fast. This way,
>instead of 32 ... we can have 2^32! :)
>
>Just my comment ... 
>
>Cesc
>
>
>On 7/16/05, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>  
>
>>Hi Daniel,
>>
>>The major drawback of the current ACL implementation is the number of DB
>>queries required for checking the membership of a user to certain groups.
>>In most real life  scenarios, there are more than 4-5 groups (ex:
>>disabled, voicemail, GW access, other service access ) - which means for
>>each INVITE you will have like 2-3 DB queries; and that's only for ACLs!!
>>
>>So, a new design which will reduce the number of queries is welcomed
>>(even required).
>>
>>Even if it's more radical, I will go for option nr 2:
>>    groups will be kept all together as a bit mask (32 groups should be
>>ok); either in a grp table, either in subscribers table
>>    the mask may be load (in an AVP??) at auth (no extra query) or on
>>request (only one query for all of them); during all script processing,
>>any group may be test as many time as wanted without any penalties; also
>>bitwise checkings will be more fast than string one.
>>    for provisioning and script fixing purposes, a second table will
>>keep the association between each group name and it's bit mask; at
>>OpenSER startup, the group name will be converted to bit mask.
>>
>>Ex:
>>    grp_definition
>>        voicemail , 0x01
>>        PSTN , 0x02
>>        conference, 0x04
>>
>>    grp (subscriber)
>>       userx,  0x03     (voicemail and PSTN)
>>       usery,  0x05     (voicemail and conference)
>>
>>
>>regards,
>>bogdan
>>
>>Daniel-Constantin Mierla wrote:
>>
>>    
>>
>>>Hello,
>>>
>>>the access control list in openser is based on group membership
>>>checking which does a database query each time when user's ACL is
>>>verified. We are considering to optimize this operations since they
>>>are very often used and propose the following solutions:
>>>
>>>1. Load all groups to whom an user belongs once per request processing
>>>(one database query) and then store some bitmap flags to be used
>>>further when doing group checking. At start up time, some fixups will
>>>be made to replace the names with positions in bitmap
>>>- advantages: the old group table structure is used and changes in
>>>script should be minimal
>>>- disadvantages: after loading all group names, string comparisons are
>>>required to set the bitmap
>>>
>>>2. Introduce a new column in the subscriber table that stores the ACL
>>>bitmap and load it once per request processing
>>>- advantages: very fast load and checking -- old version of group
>>>membership checking is kept
>>>- disadvantages: more complex provisioning system
>>>
>>>What do you think? Any other idea?
>>>
>>>Daniel
>>>
>>>
>>>_______________________________________________
>>>Users mailing list
>>>Users at openser.org
>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>      
>>>
>>_______________________________________________
>>Users mailing list
>>Users at openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/users
>>    
>>
>>
>
>  
>