Re: [Isms] Moving into some design / architecture issues of ExtendedVACM

[kaushik <kaushik at cisco.com>]

Hi Juergen,

I like the approach you have proposed to have the RADIUS user-to-group
mappings and VACM user-to-group mappings in separate tables and have a
control table to decide precedence.

Regards,
 kaushik


On 6/14/09 6:12 AM, "Juergen Schoenwaelder"
<j.schoenwaelder at jacobs-university.de> wrote:

> On Sat, Jun 13, 2009 at 07:20:12PM +0200, Dave Nelson wrote:
> 
>> Or course, there *are* some models of disparate authentication systems used
>> in a precedence relationship.  For example, consider NIS and /etc/passed as
>> used for UNIX login.  The key is that there *is* a precedence relation, and
>> you won't find NIS populating /etc/passwd with user entries.
> 
> SNMPv3 currently does not have this for authentication and it does not
> have this for authorization. To fix the multiple ACM issue, one would
> have to extend the SNMPv3 infrastructure with a table that controls
> how multiple ACMs each implementing the isAccessAllowed() ASI would
> work together. One option is of course to have priorities. If we would
> have something like this, we could have a RADIUS VACM MIB module which
> provides a security name to group name mapping based on RADIUS policy
> information and otherwise reuse VACM access rules. Then the new ACM
> control table would allow me to specify whether RADIUS takes
> precedence or not and I can have my fallback config in the VACM MIB
> that is being used when RADIUS fails.
> 
> This might be the cleanest solution. But getting this right does
> require some great deal of help of some SNMPv3 seniors...
> 
> /js