[asterisk-dev] Asterisk 12 API improvements

[David M. Lee]

On Dec 3, 2012, at 2:55 AM, Olle E. Johansson wrote:

> 
> 1 dec 2012 kl. 14:24 skrev Joshua Colp <jcolp at digium.com>:
> 
>> 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?
>> 
>> I think a complete authorization system with permissions would be great but starting out should not be a blocker. The design of the overall API should also not forbid such a thing.
>> 
>> Why do I say this?
>> 
>> From my personal experience and seeing what others have done the view of a permissions system vastly differs and can really end up being application specific. Expressing this in a generic fashion is really hard. Take AMI classes - is everyone *really* happy with them? I'm not. If you are clever there are ways around them. That's not to say they don't get some jobs done.
>> 
>> Gathering what people want from such a permissions system and tackling that in parallel would be awesome. This may actually end up really illustrating the different views of permissions and how one size can not fit all unless the deployer just submits and accepts it, but that's a wild guess. So don't just say you want one, say what you need from it. This is a chance to get it right - so don't just leave it up to guessing.
> 
> I stated clearly the goal - to be able to host multiple companies in one PBX. What part of that was unclear, Josh?
> 
> Of course there are many other goals around, but this has been my focus for quite a while, with multiparking, context for originate and redirect any many other patches.

First, thanks for the feedback! To echo what Josh (and now Matt) said, the primary intention is to avoid the trap that is AMI permission classes: ending up with what looks like a reasonable set of permissions, but when you push on them you find tricky and hard to fix privilege escalation issues. If we can gather good use cases around authorization up front, we can design a scheme that addresses the use cases while avoiding the pitfalls. Well, that's the goal.

You do make a very good point to consider: per-object authz.  And at the time, I was thinking entirely of system-wide authz. Per-object schemes have their own sets of issues, but not the sort of privilege escalation issues you get with fine-grained permissions.

But about your specific use case "be able to host multiple companies in one PBX". The users of the API aren't going to be the customers or end users: they're going to be the applications. I'm assuming that it would be atypical to give access to the API directly to the end user. That would be like giving them command line or AMI access.

Instead, users will interact with the applications. At that point it's up to the applications to determine a) who the user is, and b) what that user has the right to do. And defining the permissions for the application usually makes more sense in terms of application level concepts instead of the lower level concepts. At that point, it's better for everyone if the application to do its own authorization, rather than try to shoe-horn itself into whatever's provided by the underlying system.

There may be other reasons to add per-object authorization to the API work. But hosting multiple companies in one PBX doesn't feel like one of them.

> /O

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121203/0d9734ba/attachment.htm>