Hi Supun, In order to give you an exact picture of what we ideally need to have when it comes to device policy management, I would like to take a combined scenario of both your examples mentioned above.
Consider we have three concrete user defined policies readily available to be applied to enrolled devices as follows. [1] Policy A : Assigned Criteria - All android devices Configured Features - Wifi, Camera disable [2] Policy B : Assigned Criteria - All android, BYOD devices Configured Features - VPN [3] Policy C : Assigned Criteria - All android devices used by Managers Configured Features - Camera enable Following picture depicts how these three policies would affect four sets of devices. [1] Android, COPE devices not used by managers - Only policy A would be applicable. [2] Android, BYOD devices not used by managers - Both policy A and B would be applicable. [3] Android, COPE devices used by managers - Both policy A and C would be applicable. [4] Android, BYOD devices used by managers - Policies A, B, and C would be applicable at the same time. In situation [1], we have only one policy applicable; i.e. Policy A which can be straight away applied to the mentioned set of devices. In situation [2], since there exist no conflicts in between the set of configurations of policy A and B, we can either apply two policies separately to the mentioned set of devices or think of one merged policy which combines the configurations of both A and B to be applied. Considering the fact that maintenance is easy in keeping one effective policy for a device, policy merging can be understood as the ideal approach here. Even in situation [3] and [4], since policy A and C hold feature wise configuration conflicts, applying the policies separately does not seem to be practical and thinking of resolving the prevailing conflicts and merging all resolved feature configurations into one effective merged policy seems to be the ideal approach. Thus, there is no doubt that "Policy Merging" is the way to go forward. However, in the current implementation of device policy management, we do not support policy merging. As a result, when multiple policies become applicable for a set of devices, we come into situation of considering that having multiple policies, applicable for a set of devices as the conflict and resolving it by choosing one effective policy out of them based on a pre-assigned priority per each policy. When compared with policy merging, this approach does not carry any advantage, but only disadvantages. For example, let's take the same scenario mentioned above. In situation [2], even if the two policies (A and B) do not carry any feature wise conflicts, if B has the higher priority, only B would get apply to mentioned set of devices and both WIFI and Camera feature wise configurations from policy A would be disregarded which should not ideally be the case. This disadvantage is even visible in situation [3] and [4]. If an administrator still wants to configure those disregarded configurations to the applicable set of devices, in such a scenario with no policy merging support, no matter how complex they are, he or she would have to reconfigure them back in the policy with highest priority as well, which is the second disadvantage. Not to mention how complex this task would be when there are multiple overlapping situations and multiple applicable policies wth complex feature configurations. Thus, I am saying it again, there is no doubt that "policy merging" is the way to go forward. But even with "Policy Merging", it is interesting to see how "Conflict Resolution" should happen. In here, a conflict means not multiple policies applicable to the same set of devices, but different configurations of the same feature in between multiple applicable policies to the same set of devices. For example, the different camera configurations of policy A (disable Camera) and policy C (enable Camera), applicable for Android devices used by managers. In order to resolve this conflict, we can of course use the existing policy level priority model as a good starting point. Priorities are user-defined and If policy C holds a higher priority than policy A, then we can consider the specific camera configuration of policy C (enable Camera) as the ultimately effective camera configuration of recongnized devices. Let us first focus on policy merging with conflict resolution using the existing policy level priority model as stated above and then think of any improvements to this priority model as future work. Few improvements that I could suggest at this moment are as follows. [1] What if policy A and C have not only one conflicting feature, but many? For example, let's say we have both camera and sound level configurations in a conflicting state. When it comes to camera, an adminstrator would like to give policy C a higher priority, but when it comes to sound, the other way around. We could not support this level of granularity using the existing policy level priority model. We will have to go deep into both policy and feature level priority model to support this. [2] Although the current priority model looks simple at a glance, it's not that simple for an administrator to think of the correct priority for a policy in a hurry. As in the case of above example, when multiple policies (with and without conflicts) become applicable for the devices with various overlapping situations, an administrator would have to do lot of thinking behind the scene in order to define a correct priority for a policy. What if we can support much of this thinking load from the system itself? For example, what if the system can do the math in identifying situations with multiple policies having conflicts do become applicable for some specific set of devices and present such situations directly to the user to get a decision? For example, consider situations [3] and [4] from the above example. Without letting the administartor to identify such scenarios, the system itself would identify such scenarios and present to the user. With in a moment of time, an administartor would know which policies do have conflicts in which features and for which sets of devices. After getting to know all these facts from a reliable system, what's left for him to do is just setting up correct priorities for the conflicting policies, so that the correct configuration goes to the intended set of devices with no human mistakes. Cheers, Dilan. *Dilan U. Ariyaratne* Senior Software Engineer WSO2 Inc. <http://wso2.com/> Mobile: +94766405580 <%2B94766405580> lean . enterprise . middleware On Fri, Sep 9, 2016 at 1:53 AM, Geeth Munasinghe <[email protected]> wrote: > IMO, I would prefer first solution in which any conflict arises, we choose > the feature in highest priority policy to be in the composite policy. I > think it is a simple solution which can implemented easily and end-user can > understand easily. > > I am -1 with implementing a policy conflicts resolution mechanism, because > of the complication it has. First, policies are just syntaxes without any > meaning (semantic) to the system. Semantic of the policy comes from a user > (mostly administrator). Because only human understand the company hierarchy > and structures. It is a human who gives a meaning to the role such as who > is a developer or a leader. In the implementation of the policy, it does > not have this details, it has rules as roles which are represented by > strings. > > Second, until a device details are provided to the policy engine, it does > not know the combinations of the policies which would be merged together to > get the single effective composite policy. The composite policy will be > calculated after policy engine evaluate all the available policies with > provided rules. Rules can be related to roles, users, device types, > specific devices, temperature, speed, location of the device, time etc... A > policy could have more than a single rule, such as a policy could have > rules related to two roles, location of the device, time of the day. And > apart from that, EMM would accommodate thousands of devices. > > Third, Our next approach of policy implementation will be real time policy > changes depending on geo-location and time. When that happens, policy > engine will not be able to pick up the conflicts until those rules are > fulfilled by the devices. Let's assume that we have a policy which should > be applied to certain devices at certain time on a certain location. Until > devices is carried to that location at that time, this policy will not be > evaluated as a candidate for the composite policy. > > Therefore it is hard to predict which combination of the policy will be > applied to devices and which policies will be in conflicts and then ask > administrator to change them when we detect conflicts. And with the > complications it would present to the end-user in understating how policy > management work, I am not able to justify the value it would add to the > product. > > Therefore my personal opinion is to go with the simple solution which > would make it easier to implement and easier to understand. So I am +1 for > the first approach. In that approach administrator should prioritize the > policies according to the company hierarchy. Policies for higher company > positions should have highest priorities. And wise versa, for lowest > positions should have lowest priorities. Then in any conflicting scenario > would be resolved by selecting the feature from the highest priority > policy. > > Thanks > Geeth > > On Wed, Sep 7, 2016 at 11:30 PM, Supun Wanniarachchi <[email protected]> > wrote: > >> Hi All, >> >> Existing CDMF device management policy enforcement implementation in EMM >> supports applying only one policy upon devices based on an >> administrator-defined priority order. >> >> For instance, assume an instance where two policies (mentioned below) are >> supposed to be applied on managed devices. >> >> 1. Disable camera on all android devices -> Policy_B >> >> 2. Disable wifi on all android devices which belong to role "user-group >> A" -> Policy_A >> >> >> If we take an android device which belongs to a user in user-group A, >> ideally, both the aforementioned policies should be applied on the said >> device. But due to the limitations in existing policy implementation, only >> the Policy_B (First policy in the priority list) will be applied as that’s >> what’s been prioritized by the policy priority order. >> >> New Feature for Composite Device Management Policies: >> >> This new feature helps merge discrete policies together and get composite >> effective policy without any conflicts. It should be enhanced further to be >> able to merge several of such discrete policies together (i.e camera >> disable, wifi disable) and enforce a composite effective policy upon >> managed devices. >> >> But considering the above example there will be conflicting situation >> happen when we are going to merge these policies. >> >> 1. Disable camera on all android devices -> Policy_B (Android, BYOD) >> >> 2. Enable camera on all devices which belong to role "user-group A" -> >> Policy_E (Android, ANY) >> >> In this case, it’s hard to find what’s the exact operation apply to the >> device when we are creating effective policy. Previously there was not >> this kind of situation because only applied one policy using policy >> priority order. Get rid of this issue we can do policy merging task as two >> different ways(Proposed suggestion 1, Proposed suggestion 2). >> >> *Proposed suggestion 1*: >> >> [image: emm2.jpg] >> >> - >> >> Use existing priority order and get the first applicable policy if >> there’s any conflict situation. >> - >> >> Merge several of such discrete policies together and enforce a >> composite effective policy to the device. >> >> >> *Proposed suggestion 2*: >> >> [image: emm.jpg] >> >> >> >> - >> >> User can add any number of policies for different ownership, role or >> user and save. Without using using existing priority order. >> - >> >> But when we are doing “Apply changes to devices” event, it works as >> above diagram. >> - >> >> Restrict to apply two conflicting policies for one device. If there’s >> any conflicts, use the Resolution Mechanism for avoid these issues. >> >> >> Resolution Mechanism for conflicts policies >> >> >> - >> >> Mainly check the feature level of each policies. (i.e >> Passcode,Restriction,Wifi,VPN). Check feature by feature if there’s >> any conflicts(Features has different role sets). >> >> >> - >> >> Display conflicts policy details separately and allow user to change >> the applicable policy of that particular role/user. >> >> >> In PDP there’s no any conflicts for both Proposed suggestion 1 and 2. >> Check whether which device get the effective policy and do policy merging >> process. Finally apply that effective policy for the device. >> >> I think *Proposed suggestion 2* is more effective way and Please share >> your thoughts on this. >> >> >> -- >> Supun Wanniarachchi >> Intern >> WSO2, Inc. >> >> *Lean . Enterprise . Middleware * >> Mobile: +94 716326119 >> Blog: http://blog.supun.me >> [image: https://lk.linkedin.com/in/supun-wanniarachchi-21b37a97] >> <https://lk.linkedin.com/in/supun-wanniarachchi-21b37a97> >> >> > > > -- > > *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> > > _______________________________________________ > 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
