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 <ge...@wso2.com> wrote: > Hi Charitha, > > Please find my comments in line. > > On Mon, Oct 31, 2016 at 4:25 PM, Charitha Goonetilleke <charit...@wso2.com > > 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: ge...@wso2.com > 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>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
