[Freeipa-devel] RFC: freeipa-asterisk plugin

[Dmitri Pal]

On 11/01/2012 10:00 AM, Loris Santamaria wrote:
> Hi all,
>
> we plan to write a freeIPA configuration plugin for Asterisk, aiming to
> be general and useful enough to be included in Fedora and EPEL, so we
> would like to have your input on some issues before we write any code.
>
> I wrote down the plans so far on this wiki page:
>
> https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk
>
> Basically we would like to know if:
>
>       * It is ok to use cn=asterisk as the base object
>       * The planned DIT, separating object per type and not per site, is
>         ok
>       * The whole stuff of using CoS as a mechanism to apply default
>         values to every new object seems right
>
> Another issue is that Asterisk SIP objects in real life are generally
> associated with real people and with physical devices. 
>
> The physical devices are configured with a piece of software called the
> "endpoint manager", which could pull from the directory the data
> required to generate the IP phones configuration. We have to choices
> here. Store the IP phone extra data _with_ the Asterisk SIP object,
> adding a ieee802device objectClass to the asteriskSIPuser object. The
> other option is to store the ieee802device object separately in a more
> appropriate part of the IPA tree and have it reference the SIP object
> vía a "seeAlso" or "managedBy" attribute.
>
> As for linking SIP users to real people, it would be great to link the
> asteriskSIPuser object to an IPA user, but probably not all
> organizations interested in this kind of functionality for Asterisk
> would manage all of their users with IPA. What if the real user belongs
> to a trusted directory, for example? So it seems that for simplicity's
> sake we will have to store the name of the person using the phone in the
> asteriskSIPuser description attribute.
>
> Speaking of packaging, reading http://abbra.fedorapeople.org/guide.html
> it doesn't seems clear to me how to have an extra category of
> configuration pages added to the Web UI without modifying the main IPA
> page. What is the proper way to add extra pages to the web UI ?  
>
> Thanks in advance for your input!
>
Hello Loris,

Sorry for the delay.
I finally got a moment to read about Asterisk and looked into your plans.
Based on what you are proposing there is no real tight integration
between IPA identities and services provided by IPA and Asterisk. What I
see is IPA's DS would just be used as a data store for Asterisk
configuration data and it would be managed via CLI leveraging the plugin
framework we put together.  If such approach is interesting for a
customer I do not see a reason why it should not be done. I also do not
see a value of having such plugin as a part of the integrated IPA
supported offering. It is too independent and far from the core for us.
But it is definitely a starting point. It might change over time.

In future it might make sense to consider a different plugin that would
add schema to IPA users only and would allow users to have additional
Asterisk related attributes. I do not see a problem with user going into
IPA web UI self service to manage his personal voice mail box settings.
This seems like a logical operation. However it should be possible to
split Asterisk configuration information between IPA and some other LDAP
server or database. It might not make sense to pollute IPA with objects
and entries that do not have a good relation to what IPA is for. So the
best would be if Asterisk servers would be able to store user related
info in the identity management system like IPA while having the rest of
data about the infrastructure elsewhere. I do not know whether such
approach is possible or feasible from the Asterisk project point of
view. But if such extension for IPA users is in fact developed it has a
much better chance to become over time a part of optional but supported
portfolio of IPA plugins. No guarantees but at least such approach would
be much closer to the core of what IPA is.

We also took as stab at recommendations about writing such plugins.
The list of things to consider turned to be long and scary.
It is definitely a candidate for the external plugin development guide
or alike but we do not have time to spend cycles to create such a guide
now. We are still discussing how to better deliver this information to
FreeIPA community and potential plugin developers like you. Please stay
tuned.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/