[Freeipa-devel] RFC: freeipa-asterisk plugin

[Rich Megginson]

On 11/01/2012 09:32 AM, Simo Sorce wrote:
> On Thu, 2012-11-01 at 09:30 -0430, 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.
> Hi Loris,
> this is really exciting!
>
>> 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
> This looks like a good choice, maybe check with the asterisk people if
> they are ok with using the name that way ?
> Anyway any product specific name would work here, as it makes it
> extremely unlikely to clash with any future work in upstream FreeIPA or
> for any custom data in users' sites.
>
>>        * 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
> CoS may have some performance implications, and some usage implication,
> you need to evaluate if you are ok with those, but in general setting
> defaults is its job so it may be a good fit.
>
> I am CCing Nathan and Rich to ask them about the CoS definitions and
> whether using that many attributes would be problematic, so far I've
> only seen CoS used for overriding a single attribute so I am not sure
> what are the implications with that many.
>
> (Nathan, Rich, can you take a quick look at the paragraph named 'CoS
> definition entries' around the middle of the github wiki page pointed by
> Loris ?)

The one major drawback of CoS attributes is that they cannot currently 
be indexed, but you could write a virtual attribute indexing plugin.  
That is, you cannot do a search like (astAccountNAT=somevalue) and have 
it be indexed.  You would have to write a virtual attribute indexing 
plugin (similar to what Roles does to allow searches like (nsRole=some 
role dn)).

>
>> 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.
> I am not sure that there is an actual 'more appropriate' part of the
> tree. Although we do manage 'devices' (computer objects) that is for
> machines that are joined to the IPA domain so it would not be applicable
> in cases where the device can't actually 'join' an ipa domain. However I
> would stay flexible here and allow both cases.
> Ie allow to have objects both within the cn=asterisk subtree or in some
> other subtree.
> The ieee802device is an auxiliary class so it can be associated with any
> object in the schema at any time. The AsteriskSIPUser is also an
> auxiliray class, so as long as you allow searches that span the whole
> tree you can allow people to choose whether to associate these classes
> to external objects or to create device objects under cn=asterisk.
> Of course you need to decide if allowing that will make your plugin more
> complex and how you will manage those objects then.
>
>> 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.
> As for devices I think it would be nice if you could allow both options.
> Some deployments may choose to provision new user accounts from the get
> go with all the data including asterisk data.
> Also putting the data on the user entry make it simpler to allow the
> user to change some of the fields in a self service fashion (assuming
> there is any attribute that users should be able to change in a self
> service way).
>
> Other deployments that may want to handle additional users may need to
> be able to add additional unrelated users though, so being able to do
> that is also nice.
>
>> 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 ?
> I will let the UI expert reply on this point.
>
>
> More questions follow :-)
>
> I am reading the project page description and I see your schema files
> needs to be converted in a format that is ok for 389 DS, that requires
> you to add the attributes and objectclasses full OIDs to the specific
> attribute/object definition, IIRC 389 does not allow for macro expansion
> of OIDs like is done in the official Digium schema files.
Right.  That is planned for a future version of 389.
>
> Btw can you explain what is the use of the AsteriskSiteDefault
> objectclass, it looks like an über-objectclass that allows to associate
> a lot of Asterisk attributes, but it is not clear why you need this
> class and why you extend AsteriskExtension with it but then add
> additional Ast attributes.
> At a quick glance it seem to defeat the purpose of the objectclass
> division done by the asterisk people.
> Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better
> not to use that prefix for custom objects to avoid potential accidental
> conflicts should they decide to add a class with that name, and in
> general it is better to avoid confusion, using a different prefix makes
> it clear that this is not an official digium object but a custom
> extension.
> Also you need an OID for this calss, do you have your own OID
> numberspace from which to assign from ?
> Otherwise we need to decide how to get you OIDs for your additional
> schema.
>
> I see also that you created some attributes that use the ipa prefix for
> their name. for these you will also need an OID, and we should probably
> agree on a subprefix you can use and that we mark as assigned to your
> plugin so we do not accidentally use a conflicting name for whatever
> reason.
> I see the actual prefix ends up being ipaAutoAst for the 2 attributes
> you defined. Perhaps if would be better to use ipaAstAuto as a prefix
> instead, and we mark the whole sub-namespace 'ipaAst' as a name space
> that you use in your plugin. (So maybe you want to use
> ipaAstSitesDefaults for your custom objectclass)
>
> To make things clearer I would suggest you to use 2 schema files; one
> with the official digium objects and an additional one that depends on
> it with the plugin custom objects.
>
> The basic DIT looks ok, but there isn't much detail on what you plan to
> put in each sub container (sorry if this should be obvious to
> Asterisk-versed people, I know the project only by name and never
> configured an Asterisk server myself).
>
>
> I see that there is a astAccountSecret attribute that seem to hold a
> clear text password ? I assume it is desired that the SIP password is
> actually *not* synchronized with the FreeIPA account password as it
> usually is transmitted in the clear by a lot of devices/SIP phones ?
>
> Can regular computers be 'endpoint' devices ? (I am thinking softphones)
> Or an endpoint is always a physical device ?
>
> As I said I am not really familiar with Asterisk configuration but all
> the plugin CLI command looks quite reasonable.
> What kind of UI do you have in mind for the Web part ?
> Something inspired by our DNS plugin ? Or something different ?
>
> Lots of questions, but you are on a good start!
> Have fun.
>
> Simo.
>