[asterisk-dev] AstriDevCon - PineMango

[Brian Degenhardt]

Sorry for the verbosity.  This is something I'm passionate about, which
gets long-winded...

Tzafrir Cohen wrote:
> On Thu, Oct 09, 2008 at 11:15:53AM -0700, Brian Degenhardt wrote:
>> Tzafrir Cohen wrote:
>> > On Thu, Oct 09, 2008 at 09:20:40AM -0700, Brian Degenhardt wrote:
>> > 
>> >> To clarify, we're talking about fine-grained auth here, not the yes/no
>> >> type in a password to use the API socket.  We currently don't
>> >> authenticate AGI scripts, cli commands, dialplan scripts, and manager's
>> >> security model is a joke.
>> > 
>> > And a reminder of what happens because of that:
>> > 
>> > If you want to write a nice little dialer and do it the right way,
>> > you have to write your own daemon that runs on a dedicated server.
>> > Little hacks like SnapDialer are indeed security holes (if you allow
>> > them to be used). If there were proper authorization through the manager
>> > interface, such dialers could have been safe.
>> > 
>> > I suspect that the same would apply to any interface you want to expose.
>> 
>> You're absolutely right here.  I'm not arguing with any of this.
>> 
>> Now that we agree that you have to write a little daemon that connects
>> to Asterisk, let's explore how that's done.  For Switchvox, we've
>> written just that for our Switchboard:
>> 
>> http://www.switchvox.com/sv?cmd=screenshots&pic=23
>> 
>> Currently this daemon uses the manager interface, which it turns out is
>> bordering on unusable to do this sort of thing.  Don't take my word for
>> it, ask anyone who's ever tried to track detailed call status over
>> manager.  One of our engineers likened it to digging through your trash
>> to figure out what you had for dinner, because there isn't a proper way
>> to just ask.
> 
> Well, your daemon does much much more than originating calls.
> Originating calls using the manager interface is simple.
> 

Manager isn't going anywhere, so if that's your preferred method, it
will likely stick around until we agree it's not needed anymore.

>> 
>> This problem needs to be fixed first.  I'm not saying fine-grained auth
>> isn't a good project, I'm just saying that having a usable API is more
>> important from my perspective.
> 
> That is indeed a different problem. So now thing of a similar problem.
> Your siwtchboard is connected to an Asterisk box (maybe several of
> those) and serves several users. You want to allow different users to
> control a different subset of extensions.
> 
> Is it possible to easily tell that an even is related to one of the
> devices in the group "company_a"?
> 
> Or do we end up again without you getting the information you need for
> your switchboard?

This is an excellent question.  I think it's possible to separate the
concept of "who" is on the phone from the details needed for
fine-grained authentication.

We've actually spent a lot of time thinking about the "who" question,
and it turns out that it can be solved without a lot of changes to
asterisk's guts.  One change that helps is in the newcdr branch,
something I've done to accountcodes, explained here:

http://lists.digium.com/pipermail/asterisk-dev/2008-May/032775.html

So assume we've conquered the "who" question, why then is it not easy to
layer on "what" they're allowed to do?  The reason is because the "what"
is largely goverened by business-rules, and the API is the thing that
allows us to govern with these business rules.  If your authentication
mechanism has to gate the usage of the API, now you're stuck in a
chicken-egg problem.  Perhaps some examples will help:

Imagine a system with company_a and company_b that shares a common PRI,
but certain DIDs are routed to company_a and others go to company_b.
Who owns the call if somebody from company_a calls company_b?  What
about if I travel to Huntsville and do a hotdesk login on Russell's
phone, then proceed to make an outbound call.  Who does the call belong
to, me or Russell?

The answer to these questions *has* to be able to come from your
framework (the orange stuff in Nir's diagram), because that's where
business rules are implemented.  Therefore, that's the easiest place to
put permissions management.

I'm not saying AAA shouldn't be done, just that we're not admitting
defeat by punting it up to the orange stuff.  As I mentioned earlier,
Switchvox has very fine-grained permissions, it's just implemented
outside of Asterisk.  In the same way, most web frameworks use
cookie-based authentication based on business rules, and forgo the whole
HTTP Basic/Digest Auth mechanisms altogether.

cheers
-bmd