[+ Adding architecture group] On Tue, Nov 1, 2016 at 12:34 AM, Charitha Goonetilleke <[email protected]> wrote:
> Hi Harshan & Geeth, > > Thanks for the pointing out above scenarios. > > @Harshan, > According to your scenario having set of devices of users who is with > particular role can be consider as a group. If you aware with the device > grouping implementation it's sharing model is also based on roles which is > in the system. So what we can simply do is, create a group using particular > user role as it's sharing role and add device to particular group when > device is enrolled. In the other hand, we are also going to create such > groups for BYOD and COPE devices separately and devices automatically upon > enrollment. Same thing can be done in this case. > > @Geeth, > Current implementation in policy core is needed to update to support for > groups which could defined by *system *(i.e BYOD, COPE, or even group > created considering user's roles as explained previously), *user *(This > is what we have currently implemented), or based on *dynamic criteria > *(According > to location, time, sensor reading, device status etc.). As you have > mentioned there is a need of having dynamic rules for policies. As same for > the policies we need to have same set dynamic rules for the analytics to > show set of Smart garbage bins which is near to full in Colombo area or to > roll out firmware upgrade for Android devices in NY. By thinking about > these scenarios it is more obvious that we need to have single solution > which could apply to all of these areas together without redundantly > implementing it in several other places. > > Therefore *dynamic grouping* would be the solution for criteria based > selection of devices. We can implement such dynamic device group easily > with CEP rules. It is the most simplest way which we could provide maximum > flexibility to the user. WDYT? > > Policy priority would be a parameter which is needed to have in the Rule > definition. Only thing is we need to opt out user based rules, role based > rules and enrollment type based rule from current implementation and opt in > group based rule definition. > > AFAIK, our real-time policy evaluation won't be affected with this since > we are computing applicable policies for device based on its belonging > groups and generate final policy definition to send to the device based on > priorities. However having more and more complex rule definitions to > evaluate for policy computing might needed additional computation and also > could not be applicable to all devices in more generic forms. > > @Geeth & Harshan > > Though your scenarios are mostly valid for Android, iOS and Windows > devices, other IoT device types need to have more generic implementation > which could facilitate generic policy rules which could provide OOB. In > device manufactures perspective, they only need to honor group definition > to map the devices in to groups and can simply create policies for groups > without going through more complex policy rules. Instead of that they can > create dynamic groups with criteria as they needed and hence it can be > reusable in other places like, analytics and operations. In the other hand > we only need to compute polices only considering groups and it would > helpful to have more flexibility and speed in real-time policy computation > and evaluation. > > @All, > Shall we have a meeting to discuss this in more details and finalize the > solution? > > Thanks & regards, > /charithag > > > > On Mon, Oct 31, 2016 at 5:47 PM, Geeth Munasinghe <[email protected]> wrote: > >> Hi Charitha, >> >> Please find my comments in line. >> >> On Mon, Oct 31, 2016 at 4:25 PM, Charitha Goonetilleke < >> [email protected]> wrote: >> >>> Hi All, >>> >>> Currently EMM has policy management implementation for Android, Windows >>> and iOS devices. Since these three device types are supposed to bundled >>> with IoTS, and as IoTS device types are also needed to have policy >>> management, we need to have more generic policy management mechanism and >>> UIs to implement the policy flow. >>> >>> Current policy implementation(*Fig 1*) is highly bound to device type. >>> When user selected a device type from policy wizard, specific UI will >>> provide to set device configuration profile. Currently device configuration >>> profiles are only available for Android, Windows and iOS devices, and >>> implemented in a single unit without separating them. So those UIs can't >>> easily reuse with new device types. However after creating configuration >>> profile and rules, back end receives policy payload in generic form and it >>> has device type, configuration json and rules. Thus the received payload >>> format is generic, it is in the same format for all device types and stored >>> in the db. >>> >>> Device type plugin is retrieving stored policy from the database and >>> sending to device when needed. So the plugin takes responsibility of >>> converting the device configuration profile in to a specific form (i.e json >>> for Android, plist for iOS etc.) which could be understandable to the >>> device. Also plugin takes responsibility of checking the compliance when >>> ever needed. >>> >> >>> Fig 1 >>> >>> In order to generalize the policy implementation, we need to; >>> >>> 1. Separate out *device configuration profile* setting and implement >>> separate UI unit for each device type to setup device configuration >>> profile. >>> 2. Generalize rule definitions to have simple group based rules to >>> support for all devices. >>> 3. Modify policy retrieval mechanism to filter out applicable policy >>> for each device when relevant device type plugin is asked to evaluate or >>> send policies to particular device. >>> >>> As we are in the process of separating out the UI elements of device >>> configuration profile page, it is only needed to implement the 2nd and 3rd >>> functionalities. >>> >>> *Generalize rule definitions* >>> >>> - Current rule definition has option to select devices enrolled with >>> BYOD or COPE scenarios. But it is only applicable for EMM devices. But we >>> can introduce two groups to include BYOD and COPE devices and devices >>> applicable to these two scenarios can add in to relevant group during the >>> enrollment process. >>> - With current implementation rules can be defined by owner's role >>> or owner's name. However as long as device could have multiple users via >>> device grouping and there is no any visible mapping between devices and >>> user roles directly this rule become more complex and need to have >>> complex >>> evaluation. So the best way is simply show accessible groups which >>> belongs >>> to user and define the rule based on that. >>> - Also it is not possible to apply policy for single device with the >>> current implementation. But if we wants to add policy for single device >>> it >>> is also possible as long as device goup could have any number of devices >>> >>> >> >>> *Modify policy retrieval mechanism* >>> >>> - Current rule definitions make more complex policy retrieval >>> mechanism as it has criteria with enrollment type as well as user names >>> and >>> roles. But having only group based rule, we can simply get the groups >>> which >>> particular device is belonging and compute the applicable policy for >>> device >>> by evaluating the policy priority. >>> >>> Grouping as a rule is already added to the policy core, but we have not >> added the relevant ui parts, due to time constraints with other priorities. >> >>> WDYT? >>> >> >> As far as I understand, having only grouping implementation will not help >> to evaluate rules well. As the current policy implementation, it can be >> extended to add more rules such as location, time and as well as >> temperature, speed etc.. And we can plug-in evaluation engines as well. >> Current evaluation engine works based on priority. >> >> So my question is how do you do a location based policy rules >> (geo-fencing) or time based policy rules with grouping ?. This is related >> to real time policy evaluation which we will have to implement in a future >> release. >> >> Current policy implementation has only tenant level isolation. But with >> grouping we have to do user level isolation for policies. Because two >> different users will have separate device grouping and they are isolated >> from each other. Therefore policies has to be isolated. (We will have to do >> this anyway.) >> >> >> >>> Thanks & Regards, >>> /charithag >>> >>> -- >>> *Charitha Goonetilleke* >>> Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 77 751 3669 <%2B94777513669> >>> Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag >>> <https://www.facebook.com/charithag>, linkedin: charithag >>> <http://www.linkedin.com/in/charithag> >>> >>> <http://wso2.com/signature> >>> >> >> >> >> -- >> >> *G. K. S. Munasinghe* >> *Senior Software Engineer,* >> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >> *lean.enterprise.middleware.* >> >> email: [email protected] >> phone:(+94) 777911226 >> >> <http://wso2.com/signature> >> > > > > -- > *Charitha Goonetilleke* > Software Engineer > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 77 751 3669 <%2B94777513669> > Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag > <https://www.facebook.com/charithag>, linkedin: charithag > <http://www.linkedin.com/in/charithag> > > <http://wso2.com/signature> > -- *Charitha Goonetilleke* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 77 751 3669 <%2B94777513669> Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag <https://www.facebook.com/charithag>, linkedin: charithag <http://www.linkedin.com/in/charithag> <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
