Hi Harshan, We do have basic COPE capabilities out of the box. This system app is for the customers with their own firmware in place/can get access to firmware/can get our app signed by firmware signing key. This system app enables them to do a lot of advanced stuff. But as you said, in future we must also get partnered with vendors so that we can also have our own version of agent/system app (vendor signed) hosted on cloud (or play store) so that clients can directly download the agent from there.
Approach that other EMM vendors follow is similar, they have "System service" apps for all the vendors in play store. (ex: search for "<EMM Vendor Name> <Device Vendor Name> service" in play store). So we will also have to get something similar done in future. Thanks On Fri, Jan 29, 2016 at 9:33 AM, Harshan Liyanage <[email protected]> wrote: > Hi Kasun, > > Please find my comments inline. > > [1] How is the corresponding signing process going to happen? Who should > take the ownership of it? > > - It's totally up to the client to get our system app signed by the > firmware signing key. Usually these kind of scenarios mostly applicable for > devices which are custom made for an organization. Those organizations may > have contracts/agreements with device vendors. So they can get our EMM > system app signed by the same key used to sign the firmware. Once an APK > file is signed, it can be installed to all the devices as a normal app. > Signing is a one time process. > > So basically this means we only support COPE for organizations who are > having their own firmware. How do we plan to support COPE scenario for > organizations without having their own firmware? I think in that case we > need to take the ownership and get the apk signed by device vendors like > other EMM vendors do. > > Thanks, > > Harshan Liyanage > Software Engineer > Mobile: *+94724423048* > Email: [email protected] > Blog : http://harshanliyanage.blogspot.com/ > *WSO2, Inc. :** wso2.com <http://wso2.com/>* > lean.enterprise.middleware. > > On Fri, Jan 29, 2016 at 8:39 AM, Kasun Dananjaya Delgolla <[email protected] > > wrote: > >> Hi Dilan, >> >> Please find the answers to your questions, >> >> [1] How is the corresponding signing process going to happen? Who should >> take the ownership of it? >> >> - It's totally up to the client to get our system app signed by the >> firmware signing key. Usually these kind of scenarios mostly applicable >> for >> devices which are custom made for an organization. Those organizations may >> have contracts/agreements with device vendors. So they can get our EMM >> system app signed by the same key used to sign the firmware. Once an APK >> file is signed, it can be installed to all the devices as a normal app. >> Signing is a one time process. >> >> >> [2] How is this going to affect the typical device enrollment process of >> emm? Can you point out the changes? >> >> - There won't be major changes on the enrollment process and we have >> several approaches to get this additional system application pushed >> to the device. They are as follows. >> - In COPE mode (when the organization has its own devices to be >> given to employees), agent app and the system app can be side loaded >> (pre-installed) to the devices. >> - When above step can not be done, this system application can be >> downloaded and installed to the device during the enrollment process. >> - When this need to be done in enrollment process, it can either >> be auto-installed (since we have system privileges) or we can auto >> trigger >> the app download + prompt the installation after the enrollment. >> >> (Keep in mind that this system application is applicable only when the >> device owner has system/root level access to the devices and ONLY in COPE >> scenarios.) >> >> Thanks >> >> On Thu, Jan 28, 2016 at 10:57 AM, Dilan Udara Ariyaratne <[email protected] >> > wrote: >> >>> Hi Kasun and All, >>> >>> I am having following questions to be clarified on this regard. >>> >>> With this approach, can you also explain : >>> [1] How is the corresponding signing process going to happen? Who should >>> take the ownership of it? >>> [2] How is this going to affect the typical device enrollment process of >>> emm? Can you point out the changes? >>> >>> Thanks, >>> Dilan. >>> >>> >>> *Dilan U. Ariyaratne* >>> Software Engineer >>> WSO2 Inc. <http://wso2.com/> >>> Mobile: +94725197942 >>> lean . enterprise . middleware >>> >>> On Tue, Jan 26, 2016 at 11:48 AM, Kasun Dananjaya Delgolla < >>> [email protected]> wrote: >>> >>>> Hi Inosh, >>>> >>>> No one can disable/remove a system app unless the user has root access >>>> to the device or the system app is disabled by another device administrator >>>> app. >>>> >>>> Also +1 for the concern of tracking the system app status in the server >>>> side. Main concern for coming up with this system app was targeting the >>>> customers who has firmware access or who can get vendor signing done. But >>>> totally +1 to make it more flexible as you suggested. And I should also >>>> mention, the agent app is anyways executing the system operations only if >>>> the system app is available. So that is anyways handled that way. >>>> >>>> Thanks >>>> >>>> On Tue, Jan 26, 2016 at 11:33 AM, Inosh Perera <[email protected]> wrote: >>>> >>>>> Hi Kasun, >>>>> >>>>> This system service runs as a separate service where our android agent >>>>> application can invoke this service to get above operations executed. >>>>> I think another usage of this would be in case, we managed to get some >>>>> vendor signing our-selves, these service apps can be hosted in a public >>>>> location such as Google playstore which can be used in a cloud based >>>>> scenario. I think the same approach is followed by other EMM solutions in >>>>> could deployments. >>>>> >>>>> Is there any possibility of disabling the service app? usually system >>>>> services are grayed out in apps, so probably not, isn't it? >>>>> Also, I suggest we have a way to inform EMM server at the device >>>>> enrollment, telling that the device has the service app installed or not. >>>>> Only if it is installed, the server should be able to send operations that >>>>> requires root access. Also if the service app is not installed and there >>>>> must be a way to add an app policy to the device asking to install the >>>>> service app. This also depends on company requirement, therefore we must >>>>> have a setting at the server side to set if the service app is required or >>>>> not. >>>>> >>>>> Regards, >>>>> Inosh >>>>> >>>>> On Tue, Jan 26, 2016 at 10:58 AM, Kasun Dananjaya Delgolla < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> We have come up with the following architecture for the $subject >>>>>> after going through the possibilities. This is basically for COPE >>>>>> (Corporate Owned Personally Enabled) devices. This system service will >>>>>> basically require root (system level) access from android system. >>>>>> Therefore >>>>>> this can be used when the device has corporate owned (customized) >>>>>> firmware >>>>>> or when there's a possibility of vendor signing [1] the system service >>>>>> app. >>>>>> In these scenarios above mentioned system service application will run >>>>>> as a >>>>>> system app in the device. >>>>>> >>>>>> The reason for us to come up with this approach is to enable >>>>>> enterprises to have full control over the devices (COPE) by enabling >>>>>> system >>>>>> level features such as silently install/uninstall apps, execute shell >>>>>> commands as super user, reboot device, retrieve system logs, OTA (Over >>>>>> The >>>>>> Air) update device firmware control advanced system settings etc. >>>>>> >>>>>> This system service runs as a separate service where our android >>>>>> agent application can invoke this service to get above operations >>>>>> executed. >>>>>> Reason for us to separate this service from our agent app is to have the >>>>>> flexibility of using a single agent app for both COPE and other >>>>>> (BYOD/Mixed) scenarios. So the agent app will externally invoke this >>>>>> service in cases of COPE operations mentioned above. Basic communication >>>>>> flow is as follows, >>>>>> >>>>>> >>>>>> >>>>>> *Security level* >>>>>> >>>>>> To make the system service secured, we made the system serviced >>>>>> access level to "signature"[2]. This means only the apps signed with the >>>>>> same key as the key used to sign the system service ONLY can access the >>>>>> system service application. Therefore the EMM Agent app and the system >>>>>> service need to be signed with the same signing key when deploying. Also >>>>>> the system service will not be visible in the foreground in any scenario >>>>>> since it's a standalone service runs in the system. >>>>>> >>>>>> Two apps will communicate by using the Messanger/Handler >>>>>> mechanism[3]. [4] for further explanations on the communication protocol. >>>>>> >>>>>> Please go through the above and reply to the same thread if you have >>>>>> any concerns. >>>>>> >>>>>> >>>>>> [1] - https://source.android.com/devices/tech/ota/sign_builds.html >>>>>> [2] - >>>>>> http://developer.android.com/training/articles/security-tips.html#IPC >>>>>> [3] - >>>>>> http://developer.android.com/guide/components/bound-services.html >>>>>> [4] - >>>>>> http://www.truiton.com/2015/01/android-bind-service-using-messenger/ >>>>>> >>>>>> Thank you >>>>>> >>>>>> -- >>>>>> Kasun Dananjaya Delgolla >>>>>> >>>>>> Software Engineer >>>>>> WSO2 Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> Tel: +94 11 214 5345 >>>>>> Fax: +94 11 2145300 >>>>>> Mob: + 94 771 771 015 >>>>>> Blog: http://kddcodingparadise.blogspot.com >>>>>> Linkedin: *http://lk.linkedin.com/in/kasundananjaya >>>>>> <http://lk.linkedin.com/in/kasundananjaya>* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Inosh Perera >>>>> Software Engineer, WSO2 Inc. >>>>> Tel: 077813 7285, 0785293686 >>>>> >>>> >>>> >>>> >>>> -- >>>> Kasun Dananjaya Delgolla >>>> >>>> Software Engineer >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> Tel: +94 11 214 5345 >>>> Fax: +94 11 2145300 >>>> Mob: + 94 771 771 015 >>>> Blog: http://kddcodingparadise.blogspot.com >>>> Linkedin: *http://lk.linkedin.com/in/kasundananjaya >>>> <http://lk.linkedin.com/in/kasundananjaya>* >>>> >>> >>> >> >> >> -- >> Kasun Dananjaya Delgolla >> >> Software Engineer >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> Tel: +94 11 214 5345 >> Fax: +94 11 2145300 >> Mob: + 94 771 771 015 >> Blog: http://kddcodingparadise.blogspot.com >> Linkedin: *http://lk.linkedin.com/in/kasundananjaya >> <http://lk.linkedin.com/in/kasundananjaya>* >> > > -- Kasun Dananjaya Delgolla Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware Tel: +94 11 214 5345 Fax: +94 11 2145300 Mob: + 94 771 771 015 Blog: http://kddcodingparadise.blogspot.com Linkedin: *http://lk.linkedin.com/in/kasundananjaya <http://lk.linkedin.com/in/kasundananjaya>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
