[asterisk-dev] Introduction to ASA - the Asterisk Security Architecture

[BJ Weschke]

Johansson Olle E wrote:
> Friends,
> I've collected some notes and ideas and produced yet another PDF for  
> you to look at, read and then discuss.
>
> http://edvina.net/asterisk/asa-intro.pdf
>
> All feedback - positive, negative and flames - are welcome!
>
> Greetings from SIPit in Lannion, France :-)
>
> /Olle
>
> Who got some extra time after missing a train in Paris...
>   
 
Olle - 

 My apologies for late feedback on this, but I've just gotten a chance to read through your document. I've been putting some work into projects recently using the Java Spring framework and the way that they've approached security with Spring Security I think might apply here too. 

 In a nutshell, Spring Security is an "add on" project to Spring itself. It's not critical to the core itself, but when you choose to use it, there is very tight integration between core components and the security providers. You then have an authentication object which provides authentication of users which either says they're authenticated or not and then provides a defined role with that login.  
 On the backside of the authentication object are pluggable providers so you can use LDAP, ODBC, SOAP over HTTPS transport, ASCII config, XML, etc to be the provider of the user, password, and role information; not very different at all from the RT driver design/architecture. 
 With the authentication model in place, this then allows for the implementation of filters and proxies which can query the authentication object for valid user access and the defined role of that user. The filter or proxy then gets to make the decision (eg - ACL) what resources the request is allowed access to based on (a) successful authentication (b) the role. 

 I think this model is a good fit for the security discssion going on here as well because it leaves enough flexibility for the security model to be "something to everyeone" for lack of a better term. The only thing that I see missing might be the addition of a domain or realm to the user and role portions to allow for proper partitioning across the authentication model. 
 I am a pretty firm believer though that the level of authentication should really stop after the collection of user / password. I'm not really a fan of additional code to do IP mask checks,etc because such a thing isn't a core competency of Asterisk in the first place. There's plenty of other utilities/packages out there that do a better job then Asterisk does now at IP level ACL and should and will be used already by any Asterisk implementation that is properly designed/secured. We don't need to reinvent the wheel here.

 As it relates to the PineMango discussion/thread, I would hope that PineMango would at some point be built with a inseperable filter that makes use of the authentication layer. Once authenticated, each PineMango request would then have that "user object" bound to the request. In an ideal world, the core component that receives the request to be serviced would then look at that user object and make a decision that based on their role, they're then either allowed to have that request serviced or not. 
 However, to bmd's points made, which are 100% valid, if we implement this I'm sure that even 5 years from now there will still be components that haven't adopted the new model. Such is the nature of any large open source project. This should not be a hold up to PineMango itself. I do agree with oej though that if we don't do "something" from the start, we'll probably never go back and do it "right". 

 Suggestion/Thoughts: I think we should take some sort of security model into consideration from the get go in the construction of PineMango. Even if the rest of the security model itself doesn't exist yet, we should design and build out the stubs that carry the user object across to the component servicing the request. Then, if we get to the servicing component and there's no callback that knows how to deal with the new information, you could have a configurable setting at the global level that will either accept or reject requests to components that aren't yet coded to deal with the new request context. In the beginning, for anything in PineMango to be functional, the default will need to be "allow", but as time goes on and more components change over, it will then be up to the individual installer/integrator/admin on how secure they want their system to really be. 


 BJ

--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/