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>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
