Re: [Isms] Moving into some design / architectureissues ofExtendedVACM

["Dave Nelson" <d.b.nelson at comcast.net>]

David Harrington writes...

> For non-emergency uses, RADIUS could specify the precedence
> order for a group, but somehow, the security admin needs to be
> able to say that "this group needs authorization to override 
> a RADIUS rejection".

I think you're making this *way* too complicated.

First, I don't believe there is a real market requirement for
fine-granularity precedence of AAA sources.  One can posit hypothetical
scenarios where it could be useful, but I think that's outside the
80-percent problem.

Second, no one should *ever* be able to override a RADIUS reject.  If there
is a problem with the RADIUS service, then a good design is to have one (or
a very small number) of locally configured user identities that bypass
RADIUS altogether -- the analog of the "root" account in the /etc/passwd
file.  Having a simple selection mechanism to choose between using RADIUS or
local data is sufficient, and that could be as simple as "root" is always a
local account.

Once you get into the business of second guessing the authoritative AAA
service, as to access control decisions, "Abandon Hope All Ye Who Enter
Here".