[asterisk-dev] Asterisk 12 API improvements

[Tilghman Lesher]

On Mon, Dec 3, 2012 at 12:30 PM, Matthew Jordan <mjordan at digium.com> wrote:
> On 12/01/2012 02:10 AM, Olle E. Johansson wrote:
>> "Authorization: No immediate need for multiple levels or granular permissions inside the api."
>>
>> I disagree. Some of my patches have been focused on being able to host multiple companies in one PBX.
>> We do need authorization so we can implement "realms" within Asterisk - which channels are one
>> particular user (or group) allowed to follow, manipulate and originate?
>>
>
> It feels like this could be broken up into Identity - being able to
> associate groups of endpoints/channels with a particular domain - and
> authentication/authorization - i.e., who can see who and what a client
> can do.
>
> I'm definitely behind the idea of Identity - there should be a way to
> differentiate between clients of the API.

At the core level, all that's really needed are append-only tags.  Tag
a channel with an identifier at the peer level or in the dialplan, but
once a tag is applied, it cannot be removed until the channel is
destroyed.  Tags should be inherited along bridges; additionally,
there should be effectively an unlimited number of tags per channel.
In terms of consumers of the tags, as long as the tags are passed back
with events, you can allow further limiting solutions (authorization)
to arise organically as providers need them.  This is extremely simple
to implement and won't bog down the core with the details of
authorization.  As long as the tags cannot be modified after appending
to the channel, the edge users can rely upon their presence to
indicate something.  (What do they indicate?  We can leave that to
various solutions providers to define.)

> Authentication/authorization is tricky.  It'd be nice if that could be
> deferred outside of the API itself to some external provider, i.e., you
> tell Asterisk how who can see who and how.

It definitely needs to be outside of the core API, but it could still
be implemented within the PBX via plugin module.  Again, as long as we
provide the tagging, then we don't need to concern ourselves with the
actual details of the authorizations.

I think we should leave any plugin authorization inside the core out
of the initial design, and let actual providers suggest the plugin
architecture, once the tagging is available.  That ensures that where
the hooks are placed and what information is passed back is based upon
real world needs, not theoretical constraints (constraints that might
never be useful but would otherwise need to be maintained).

-Tilghman