.png "Menu")
Data Containerization for WSO2 EMM Android agent
A post describing the value of the Internship experience at WSO2 will be published later and this is just about one task I've done while in my internship.
Requirement
When we consider an EMM user with an Android Device belongs to BYOD scenario, the agent is existing in the middle of the user's personal information store. So, there is always the risk that an app which user installed for his personal use can access the Enterprise details (such as Enterprise Email Inbox, Enterprise Docs) since they are also stored in the same place. On the other hand, the user may be worrying that the Admins of EMM can access his personal information (the agent already has permissions at the beginning since it is necessary to do operations). Due to these reasons, we went for containerizing the data and create a separation between Personal Data and Enterprise data and both can't access beyond their space (container).
Implementation
The implementation was done using the feature called 'Managed Profile' which comes in the devices with Android Lollipop upwards. When the agent is launched in the device, it checks whether the device is compatible for this feature. If so, it will prompt user to setup the profile before enrollment (figure-1). Even though the device is recognized as capable to setup the managed profile, there are times where it fails because of the customizations done to the OS by some of the Mobile Device Company (Ex: The managed-profile doesn't work properly on Asus Zenfone 2 which has Android Lollipop).
By pressing ‘Setup work-profile’ user is redirected to the manage profile creation wizard (figure-2). Once the profile setup is done, the Agent automatically copied into the new profile. For here on the Agent in the personal profile (which was downloaded earlier) is not needed since we do enrollment for the Agent which is in the newly created managed profile (which is also called work profile). So the user is informed that and ask to uninstall the agent in personal profile to ensure that there is no any enterprise bits in his personal space. Then, the ordinary enrollment happens through the EMM agent in the work profile (figure-3).
After these steps, if you go to the launcher of the device you will see duplicate icons of some apps with a little batch of a bag attached (figure-4). Those are the apps in the work profile. You will also see EMM agent has such a batch, that's because it is also installed in the work-profile. The advantage of this arrangement is that the user don't have to do any kind of switching between personal profile and work profile as all the apps in both profiles appear in the same launcher. But note that according to the underlying architecture, the profiles have their own storage places which can not be access by each other (unless grant special permissions by Agent).
Change of Operations
Since it is EMM agent who has created the work profile, it becomes the Profile Owner of the work profile. Therefore the agent receives total control of the work-profile. But nothing more than that! ; means now the agent can't do operations which happened to be affecting the whole device such as Wipe operation, Change PIN operation.
Also the restriction of Camera will only affect the Camera app in the work-profile. The user will be able to access the camera app in his personal profile. So what adding camera restriction here could done is restricting the user getting a photo and attaching it to any enterprise bits. (Personally I think that is very correct. Letting the user use his own device we shows the trust for himself in the company. If we trust the user in to that extent, then it is not necessary to apply such restrictions in device-wise.)
Apart from this the Enterprise Wipe operation will remove the manage profile including the agent.
Policy for configuring Work-Profile
EMM admin can apply a policy for devices which have the EMM agents activated in work profiles to configure their work-profiles. The admin can name,
the profile name.
which System apps have to copied to the work profile from the personal profile.
which System apps that automatically gets enabled in the work profile have to be hidden.
which System apps that already hidden have to be unhide back.
which Google Play apps have to be downloaded to the work profile. (The user will have to indicate those apps using their package names.)
Cons and suggestions for the Future.
The concept of Android Managed Profile is still new for Android. According to the changes come with the recent updates of Android, it is clear that they have started seriously looking into improving the Managed Profile Concept.
Due to security concerns of the work-profile, Android doesn't allow installing 3rd party apps in work-profile any how. What is possible is enabling system apps or downloading from Google Play Store. Therefore the main issue is that we are unable to integrate WSO2 AppManager with the work profile. (Apps downloaded by App Manager are also considered as 3rd party apps).
There is a EMM Community started by Google. The EMM vendors are encouraged to join with Google for a partnership there [3]. According to the benefits of the partnership, the vendors gain additional APIs which can be used to solve the above scenario. The process of getting partnership is still in the process. Therefore AppManager integration won't be coming with this first phase.
The server doesn't keep any record whether the device has enabled work-profile or not. It will be beneficial to keep a property in the server for that. The property can be sent along with the enrollment payload whether the enrollment has happened in a work-profile or not.
The concept of Managed-profile seems to be the future of EMM for Android. Any kind of research in future to that content won't ever be useless!
any help please with EMM
ReplyDelete