Well, supporting device identity is indeed something that's there in the product roadmap. However, that I'm afraid is out of the scope of what's proposed and intended to be discussed within this particular thread.
That said, if you are willing to contribute to the platform WRT getting device identity implemented, and also have got a design/architecture in mind, please do go ahead and initiate a separate thread in architecture@, so we can discuss it there. Cheers, Prabath On Fri, Apr 29, 2016 at 10:25 AM, Dilshan Edirisuriya <[email protected]> wrote: > Hi, > > What are the plans to support device identity? There are several > situations where you need to consider device as a top level element rather > than associating it with users. Eg; picking the device from authentication > level, adding throttling policies for device etc. > > Regards, > > Dilshan > > On 28 April 2016 at 17:56, Prabath Abeysekera <[email protected]> wrote: > >> Hi Everyone, >> >> As all know, CDM-F is a platform that allows folks to easily extend its >> plug-in model and seamlessly add support for new device types. So, ATM, >> "Device Management Plugin" is the primary top level construct that can be >> extended in the framework, to cater the aforementioned requirement. >> >> I'm proposing "Device Management Feature" too should be treated as a >> similar top-level extensible construct, particularly considering "EMM-like" >> scenarios, in which we ship a standard set of plug-ins, that needs to be >> extended to support a few new features. Here's why. >> >> Let's assume an organization is planning to deploy EMM to manage their >> devices. The list of "features" that needs to be managed by one >> organization might vary from that of another. Further, support for managing >> some of those might not even be available OOTB as part of EMM. To makes >> things more complicated, in certain cases, shipping all that sort of fancy >> features around OOTB in EMM wouldn't quite make sense as well. However, in >> the context of those adopting organizations, having the ability to control >> such features might be critical. As a result, there is always a possibility >> that these folks get lured into customize the existing functionalities if >> that level of extensibility is not available in the product. >> >> To cater the aforesaid requirement, the only option available right now >> is extending one of the existing plug-ins (with the new features) and then >> plugging the enhanced plug-in back into the product, which is somewhat a >> tedious task. >> >> To make things more easier for users, I propose making "Device Management >> Feature" an extensible construct, which can be utilized by the folks who >> want to extend an existing plug-in to seamlessly support new features that >> are not supported OOTB in the product. This can be thought of as something >> similar to the concept of "mediators" in the context of ESB as well. >> >> WDYT? >> >> Cheers, >> Prabath >> -- >> Prabath Abeysekara >> Technical Lead >> WSO2 Inc. >> Email: [email protected] >> Mobile: +94774171471 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Prabath Abeysekara Technical Lead WSO2 Inc. Email: [email protected] Mobile: +94774171471
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
