[Architecture] WSO2 Enterprise Mobility Manager (EMM) 1.0.0 Released

[Shanmugarajah Sinnathamby]

*WSO2 Enterprise Mobility Manager (EMM) 1.0.0 Released!*

*February 2014*

*WSO2 Mobile team is pleased to announce the release of 1.0.0 Version of
the Open Source WSO2 EMM.*

WSO2 Enterprise Mobility Manager (EMM) is a unique solution designed to
specifically address the mobile enterprise needs. EMM includes of two key
components: Mobile Device Management (MDM) and Mobile Application
Management (MAM). WSO2 EMM also supports single sign-on (SSO) and
multi-tenancy.

MDM enables organizations to secure, manage and monitor Android and iOS
powered devices (i.e., smart phones, ipod touch devices andtablet PCs),
irrespective of the mobile operator, service provider, or the organization.
Users need to accept the Policy agreement, which states all the actions
that can be carried out on the device when enrolling with MDM. MDM only
controls the corporate data that is present on the devices, while the
personal data is left untouched.

The administrator can create policies in MDM, and define the MDM aspect of
the policy (i.e., device management rules) via the MDM Console. EMM
policies can be set at various levels, namely user level (L1), platform
level (L2) and role level (L3). L3 policies have the lowest priority. L2
policies override L3 policies, while L1 policies override both L2 and L3
policies. When employees register their devices with MDM, the applicable
policy rules (e.g., enabling the phone lock, disabling the camera, and
more) will be enforced on their devices. WSO2 EMM constantly monitors all
the registered devices for policy compliance. WSO2 EMM will automatically
generate a notification and carry out follow-up actions in the event a
device is in violation of the enforced policy. The administrator can select
the follow-up actions (e.g., send the user a warning message, enforce the
policy again, and more) based on their security requirements.

MAM enables organizations to control corporate applications (apps) on
devices that are enrolled with the MDM. MAM consists of three key
consoles:Mobile Publisher,Mobile Store and MAM Console. Users use the
Mobile Publisher to manage enterprise apps throughout their app life cycle,
which include app states such as, published, unpublished, approved,
rejected, deprecated, and retired. The Mobile Store acts as a marketplace
and contains all the corporate mobile apps, which users can search, view,
rate and install on-demand. The administrator uses the MAM Console to
manage users, administer MAM policies, and install or uninstall mobile apps
in bulk. The administrator can define the MAM aspect of a policy (e.g.,
blacklisted apps and apps to be installed upon policy enforcement) via the
MAM Console.

An open source product, WSO2 Enterprise Mobility Manager is available under
the  *Apache Software
License (v2.0)* . This
product includes all of the extra integration and management functionality
as well.


Key Features

   -

   MDM Console
   -

  Device provisioning
  -

  Device configuration
  -

  Policy enforcement
  -

  Compliance monitoring
  -

   MAM Console
   -

  Mobile app policy enforcement
  -

  Compliance monitoring
  -

  Bulk app push
  -

  User Management
  -

  Tracking app installation
  -

   WSO2 Mobile Publisher
   -

  Mobile app publishing
  -

   WSO2 Mobile Store
   -

  User subscription
  -

  Advanced search options
  -

  Mobile App sorting
  -

  Support for existing user stores
  -

  Single-Sign on

Project Resources

   -

   *Home page : **http://wso2.com/products/enterprise-mobility-manager/
   *
   -

   *Documentation :
   *
   
*http://docs.wso2.org/display/EMM100/WSO2+Enterprise+Mobility+Manager*
   -

   *JIRA-Issue Tracker :*
   -

  *https://wso2.org/jira/browse/MDM* 
  -

  *https://wso2.org/jira/browse/MAM* 

Installation and Running

   1.

   Extract the downloaded zip file
   2.

   Run the wso2server.sh or wso2server.bat file in the /bin directory
   3.

   Once the server starts, point your Web browser to
*https://:9443/* 
   4.

   For more information, see the Installation Guide:
   5.

   On the web: 
*http://docs.wso2.org/display/EMM100/Deployment+Guide*

Bug Fixes

   -

   [*MDM-156* ] - WARN - "Product
   landing page not found" in Server start
   -

   [*MDM-201* ] - Unable to saved
   created permissions
   -

   [*MDM-211* 

Re: [Architecture] SSO IDP Proxy Application + SDK

[Shanmugarajah Sinnathamby]

Hi Prabath,

1. Can't we use the implicit  grant type instead of *Authorization code . *


   - *Authorization Code* for apps running on a web
server
   - *Implicit* for
browser-based
or mobile 
apps

Any reason why it can't be used.
Is that because we use a proxy app and client app ?

2. Also can't we eliminate the use of web view. Rather use direct calls  ?

3. Also can we have a custom grant type for mobile application , so that
same level of security is achieved ?




On Mon, Mar 10, 2014 at 10:39 PM, Chan  wrote:

> IMO we don't revoke mobile app's Consumer key and Consumer secret but
> revokes the Access token of a user. Next step for this integration is to
> map access tokens that have been issued for devices. With this integration
> EMM can revoke access of a mobile device from enterprise resources (APIs)
> completely by coordinating with IS.
>
> Cheers~
>
>
> On Mon, Mar 10, 2014 at 6:10 PM, Suresh Attanayaka wrote:
>
>> Hi Manjula,
>>
>> Let me answer inline,
>>
>>
>> On Mon, Mar 10, 2014 at 4:54 PM, Manjula Rathnayake wrote:
>>
>>> Hi all,
>>>
>>> How do we store client secret and access tokens in mobile application?
>>> Have we encrypted the client secret?
>>>
>> We can let the mobile app developer to implement his own mechanism for
>> this, or if we are supporting this at the SDK, we can use a password to
>> encrypt the client secrete.
>>
>> In case of mobile device is lost, how do we remove the mobile application
>>> subscription from OAuth server without affecting to other mobile devices
>>> which uses same application? Do we generate the applicationId together with
>>> a unique mobile Id?
>>>
>>
>> User can always revoke the tokens issued for the application. We can let
>> each application to have its own client-key, client-secrete as well using
>> dynamic client registration.
>>
>>
>>> Is the mobile IDP app code signed by a trusted cert? How does the trust
>>> relationship works with mobile IDP and WSO2IS?
>>>
>>
>> WSO2IS does not have to trust the proxy IDP in the mobile. IS will always
>> validate client-key, client-secrete and will check user authentication at
>> logins.
>>
>>
>>>
>>> thank you.
>>>
>>>
>>> On Mon, Mar 10, 2014 at 4:37 PM, Gayan Gunawardana wrote:
>>>
 Hi Nira,

 Reason to do that way is normally client secret does not share with any
 other party


 On Mon, Mar 10, 2014 at 4:24 PM, Niranjan Karunanandham <
 niran...@wso2.com> wrote:

> Hi Gayan,
>
> Here the IDP proxy app is only used to get the authorization code from
> the WSO2 IS and pass it to the SDK. After which the SDK is communicates
> directly with the WSO2 IS to get the access token and manage the access
> token and refresh token.
> Just a small clarification why we can't use the IDP proxy app to do
> this, .i.e, let the IDP proxy app manage the access token and refresh 
> token
> for each app. Therefore cutting off the connection between the SDK and the
> WSO2 IS. Here if the access token expires then the SDK will call the IDP
> proxy app to get the token refreshed.
>
>
>
>
> On Mon, Mar 10, 2014 at 3:58 PM, Gayan Gunawardana wrote:
>
>> Image attached
>>
>>
>> On Mon, Mar 10, 2014 at 3:51 PM, Gayan Gunawardana wrote:
>>
>>> Hi All,
>>>
>>> Problem: Implement SSO for enterprise mobile apps
>>>
>>> The idea is to provide SDK for mobile apps developers within the
>>> organization, then they can integrate SDK inside the application and
>>> implement SSO across required applications.
>>>
>>> Provide (SDK + Mobile IDP proxy app)
>>>
>>>
>>> To achieve above purpose we plan to utilize oauth 2.0 with 
>>> *Authorization
>>> code* grant type.
>>>
>>>
>>>
>>> Briefly Explaining message flow :
>>>
>>> Initially new application has to be registered in WSO2 IS under
>>> Oauth management and obtain client_key, client_secret, Access Token Url 
>>> and
>>> Authorize Url
>>>
>>> 1. SDK initiate the process by sending client_key, redirect_url and
>>> scope to mobile IDP proxy app
>>>
>>> 2. IDP proxy app obtain Authorization code
>>>
>>> 3. SDK (in side mobile app) receive Authorization code
>>>
>>> 4. SDK send second request directly to WSO2 IS with Authorization
>>> code, client secret and redirect_url
>>>
>>> 5. SDK obtain access token
>>>
>>> 6. Mobile app pass access token to resource server
>>>
>>> 7. Resource server contact IPD and validate access token
>>>
>>> This is much similar to Facebook approach where facebook
>>> application act as mobile IDP proxy app and they provide SDK t

Re: [Architecture] About EMM-Android Local Push Notification Mechanism

[Shanmugarajah Sinnathamby]

There are cases where we have to go with the specific approaches like local
push notification only, GCM only or both .
So if we can configure the system in a way where 3 scenarios are possible .
1. Local Notification Only (Currently this is one of the customer
requirement)
2. GCM only
3. Hybrid (Local + GCM) Option to select Local Notification for Compliance
monitoring and manual push to use GCM.


On Thu, Apr 10, 2014 at 10:56 AM, Dilshan Edirisuriya wrote:

> I believe its better to use them both since in some scenarios if we have
> dynamic policies (time based etc. ) which is created from EMM this will be
> needed. Hence we need to think about a way to have them work when
> necessary.
>
>
> On Thu, Apr 10, 2014 at 10:45 AM, Kasun Dananjaya Delgolla <
> kas...@wso2.com> wrote:
>
>> @Dilshan - We can actually allow switching. But there might be a scenario
>> where we might need both. That's totally depends on the scenario where it
>> will be used.
>>
>>
>> On Thu, Apr 10, 2014 at 10:41 AM, Chathura Dilan wrote:
>>
>>> +1 for local notifications. There are some tasks which need to happen
>>> real time and some tasks which does need to happen on time. If we can
>>> distinguish them properly we can save large amount of battery power.
>>>
>>>
>>> On Thu, Apr 10, 2014 at 10:34 AM, Harshan Liyanage wrote:
>>>
 Hi Kasun,

 I think we must implement the method you are proposing. Since this
 AlarmManager system service will wakeup our EMM agent in every 10 mins (or
 in configured intervals) it will make sure that our EMM agent is running in
 the device. Otherwise there would be no way that we could guarantee that
 EMM-agent process is running in the device.

 Thanks,

 Best Regards,

 Lakshitha Harshan
 Software Engineer
 Mobile: *+94724423048*
 Email: hars...@wso2.com
 Blog : http://harshanliyanage.blogspot.com/
 *WSO2, Inc. :** wso2.com *
 lean.enterprise.middleware.


 On Wed, Apr 9, 2014 at 9:33 PM, Kasun Dananjaya Delgolla <
 kas...@wso2.com> wrote:

> Hi All,
>
> This is to brief and discuss about the architecture of the $subject.
> So here's how it works.
>
> We gonna enable both GCM and Local push as switchable options so that
> depending on the requirement, we can choose which method to go with.
>
> Android's native service such as AlarmManager will be used to trigger
> local notifications so that it will be very effective with Battery
> consumption.
>
> On Agent launch, if the selected method is local push, Agent will
> initiate a repeating event using AlarmManager. (Ex: Repeat every 10mins).
> When the AlarmManager triggers the event, it simply get captured by the
> Local Notification Receiver resides in our EMM Agent. And then it will
> perform the necessary action (Operation/Contacting the server).
>
> I have already done a thorough testing on battery consumption using
> this method which is less than 0.5% when this service is running every 5
> minutes with a web service call.
>
> Therefore this can actually be used as an alternative to GCM. And it
> can also be used to capture violations (If the device is stolen and the
> network is switch off etc) and implement a self initiation protocol in 
> such
> cases. But IMO we should keep both the options because those 2 can come
> handy in different situations.
>
> So WDYT?
>
> Given below is how Android EMM Agent will look like,
>
> [image: Inline image 1]
>
> If you want an in-depth diagram on the current EMM Agent Architecture
> [1].
>
>
> [1] -
> https://docs.google.com/a/wso2.com/drawings/d/12LOSMJxPtcI_XXjkD5RnPp-uaJGTFtCC-MXkmPLT4LY/edit?usp=sharing
>
> Thanks
> --
> Kasun Dananjaya Delgolla
>
> Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
> Tel:  +94 11 214 5345
> Fax: +94 11 2145300
> Mob: + 94 777 997 850
> Blog: http://kddcodingparadise.blogspot.com
> Linkedin: *http://lk.linkedin.com/in/kasundananjaya
> *
>


>>>
>>>
>>> --
>>> Regards,
>>>
>>> Chatura Dilan Perera
>>> *(Senior Software Engineer - WSO2 Mobile)*
>>> www.dilan.me
>>>
>>
>>
>>
>> --
>> Kasun Dananjaya Delgolla
>>
>> Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>> Tel:  +94 11 214 5345
>> Fax: +94 11 2145300
>> Mob: + 94 777 997 850
>> Blog: http://kddcodingparadise.blogspot.com
>> Linkedin: *http://lk.linkedin.com/in/kasundananjaya
>> *
>>
>
>
>
> --
> Dilshan Edirisuriya
> Senior Software Engineer - WSO2
> Mob: + 94 777878905
> http://wso2.com/
>



-- 
*Shanmugarajah (Shan)*
Director Architecture, Enterprise Mobility
WSO2, Inc.; http://wso2.com
Email: s...@wso2.com
Mobile : +9448260
Blog: ht

Re: [Architecture] RFC: Adding support for Context within EMM using CEP

[Shanmugarajah Sinnathamby]

Hi Srinath,

Dynamic Policy is more of a context based, which is based on Location and
Time (currently 2 forms). We can have the other context to the dynamic
policy. Lets have a meeting to discuss this further. Can we have it early
next week ?



On Tue, Nov 18, 2014 at 3:42 PM, Srinath Perera  wrote:

> Hi Shan,
>
>
> Mobile context has hot topic for a long time. It comes in many forms.
>
>1.
>
>Device context - adopt the app to device
>2.
>
>Environment context - weather, noise, indoor or outdoor
>3.
>
>time context
>4.
>
>activity context - what is user trying to do?
>5.
>
>individual context -
>6.
>
>location context
>7.
>
>social context (private vs. public)
>
>
> Some of contexts are static while some others are dynamic (those we should
> be able to calculate using CEP without much trouble).
>
> I think we can add context as a service provided by EMM where apps direct
> information related to context to EMM, and EMM tracks and calculate the
> current context. (Some of these information EMM will anyway have due to
> agent) Some of these can be pushed to apps and others apps can ask for when
> needed.
>
> WDYT?
>
> --Srinath
>
>
> --
> 
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://people.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>



-- 
*Shanmugarajah (Shan)*
Director, Mobile Architecture,
WSO2, Inc.; http://wso2.com
Email: s...@wso2.com
Mobile : +9448260
Blog: http://shanfour.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] RFC: Adding support for Context within EMM using CEP

[Shanmugarajah Sinnathamby]

Thanks Srinath,
Will go through it.

On Wed, Nov 19, 2014 at 5:27 PM, Srinath Perera  wrote:

> Yes
>
> Following paper describes the idea in detail.
>
>
> https://drive.google.com/a/wso2.com/file/d/0B8UIlB9H3rv_eHlWMHNqaV9rVlk/view?usp=sharing
>
>
> --Srinath
>
> On Wed, Nov 19, 2014 at 5:12 PM, Shanmugarajah Sinnathamby 
> wrote:
>
>> Hi Srinath,
>>
>> Dynamic Policy is more of a context based, which is based on Location and
>> Time (currently 2 forms). We can have the other context to the dynamic
>> policy. Lets have a meeting to discuss this further. Can we have it early
>> next week ?
>>
>>
>>
>> On Tue, Nov 18, 2014 at 3:42 PM, Srinath Perera  wrote:
>>
>>> Hi Shan,
>>>
>>>
>>> Mobile context has hot topic for a long time. It comes in many forms.
>>>
>>>1.
>>>
>>>Device context - adopt the app to device
>>>2.
>>>
>>>Environment context - weather, noise, indoor or outdoor
>>>3.
>>>
>>>time context
>>>4.
>>>
>>>activity context - what is user trying to do?
>>>5.
>>>
>>>individual context -
>>>6.
>>>
>>>location context
>>>7.
>>>
>>>social context (private vs. public)
>>>
>>>
>>> Some of contexts are static while some others are dynamic (those we
>>> should be able to calculate using CEP without much trouble).
>>>
>>> I think we can add context as a service provided by EMM where apps
>>> direct information related to context to EMM, and EMM tracks and calculate
>>> the current context. (Some of these information EMM will anyway have due to
>>> agent) Some of these can be pushed to apps and others apps can ask for when
>>> needed.
>>>
>>> WDYT?
>>>
>>> --Srinath
>>>
>>>
>>> --
>>> 
>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>>> Site: http://people.apache.org/~hemapani/
>>> Photos: http://www.flickr.com/photos/hemapani/
>>> Phone: 0772360902
>>>
>>
>>
>>
>> --
>> *Shanmugarajah (Shan)*
>> Director, Mobile Architecture,
>> WSO2, Inc.; http://wso2.com
>> Email: s...@wso2.com
>> Mobile : +9448260
>> Blog: http://shanfour.blogspot.com
>>
>
>
>
> --
> 
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://people.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>



-- 
*Shanmugarajah (Shan)*
Director, Mobile Architecture,
WSO2, Inc.; http://wso2.com
Email: s...@wso2.com
Mobile : +9448260
Blog: http://shanfour.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Additional fields found in iOS mobile device management

[Shanmugarajah Sinnathamby]

Hi,

*1. In MDM context,  we have 3 kinds of Token*
Token, MagicToken and UnlockToken

Token,MagicToken is used for push notification from MDM Server to APNS
server
Unlock Token is used for ClearPasscode DM-Command -  to Clear the Passcode
for a Device
The size of this token is little bit large. It's server to device payload.

*2. App Push Notification (Client Agent) we have 1 Token*

This token is used to send App Push Notification from MDM server to APNS
Used for Alert Message and Location Identification.


>From the iOS MDM point of view, we have 4 Tokens

1. Tokens which are used for sending MDM Push Notification
2. Tokens which are used for sending App Push Notification but DM-Command
Specific
3. Token for DM-Command specific (ClearPasscode) for a device.

In [1] we have this for every push message to the APNS server from MDM for
each device .
[2] we have to use this for some DM-Command specific function (Alert,
Location)
[3] we have to use this for some DM-Command specific function
(ClearPasscode) -  is not used quite often.

Differences between [2] and [3]
[2] uses MDM Push Notification
[3] use APNS Push Notification

If we look at the 3 platforms (iOS,Android,Windows) , all 3 uses push
notification. But the number of tokens and the way its used is little bit
different. We can have a field called PUSH_TOKENS which is now device
independent and store the tokens as a JSON string , so each platform can
identify their respective tokens. In iOS we have DM-Command specific token
which is not used for push messages. This can be stored in a extra field
OTHER-INFO.
but it has to be key-value pair since there can be other fields.

Thanks,
Shan


On Mon, Feb 16, 2015 at 12:17 PM, Harshan Liyanage  wrote:

> Hi Dilshan,
>
> Currently the device table in mobile database has following fields.
>
>- MOBILE_DEVICE_ID
>- REG_ID
>- IMEI
>- IMSI
>- OS_VERSION
>- DEVICE_MODEL
>- VENDOR
>
> When considering iOS platform I think that we can map all other iOS fields
> to above fields except for the magic-token & unlock-token. We can map the
> push-token to REG_ID field & IMO I think that we can change the column name
> to "*PUSH_TOKEN*"  since it is more generic term than "*REG_ID*" . For
> other two tokens we can use a separate field (if we are storing 2 tokens as
> a json string if those records are not frequently accessed) or 2 separate
> columns.  In android-platform we have used WIFI Mac address as the 
> MOBILE_DEVICE_ID.
> In your case I guess we'll need a separate column for storing mac address
> too.
>
> Since all other device information (device-capacity, bluetooth mac etc)
> will be available for all mobile platforms we'll need a generic way to
> handle these. I suggest to have a separate field in our device-table like "
> *OTHER_INFO*" and store all of these other as a json string as those
> information will be accessed as a whole.
>
> @Asok : Could you please share the list of fields available in Windows
> platform?
>
> Thanks,
>
> Lakshitha Harshan
> Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>
> On Mon, Feb 16, 2015 at 11:42 AM, Dilshan Edirisuriya 
> wrote:
>
>> Hi,
>>
>> Following are the additional fields found in iOS MDM other than the once
>> we find in Android. Since our table structure is little bit tight to
>> Android platform it is necessary to identify the extension points to store
>> these fields as well along with Windows fields.
>>
>> 1) Challenge - since iOS get above information in 2 steps it has a
>> challenge password embedded in the iOS payload. This is to verify the
>> identify of the device together with its UDID.
>>
>> 2) Product - for this I will be sending this as either iPhone, iPad or
>> iPod by looking at sub-strings.
>>
>> 3) Serial - serial number of the device.
>>
>> 4) Version - iOS device type.
>>
>> 5) IMEI - IMEI number. Incase there is no IMEI number it will return
>> empty (ie iPad without the sim).
>>
>> 6) Model - model number of the device.
>>
>> 7) UDID - mapping to device identifier.
>>
>> 8) Token, Magic token and unlock token for normal push and MDM push
>> notifications.
>>
>> After the enrollment using device information command we can fetch the
>> device information such as AvailableDeviceCapacity, BluetoothMAC,
>> BuildVersion, CarrierSettingsVersion, CurrentCarrierNetwork, CurrentMCC,
>> CurrentMNC, DataRoamingEnabled, DeviceCapacity, DeviceName, ICCID, IMEI,
>> IsRoaming, Model, ModelName, ModemFirmwareVersion, OSVersion, PhoneNumber,
>> Product, ProductName, SIMCarrierNetwork, SIMMCC, SIMMNC, SerialNumber, UDID
>> and WiFiMAC.
>>
>> Please note that these fields could vary based on the OS version of the
>> device.
>>
>> We need to make these fields generic which will be helpful for the MDM to
>> fetch data accurately in generic manner as well as store them generically
>> so that any pla

Re: [Architecture] [AppM] [CDM] AppM MDM Integration

[Shanmugarajah Sinnathamby]

Hi Dilan,

The device will invoke the url to download the apk file , how do we achieve
the security .
Is there any kind of token ? or its its a direct link .

Can we have something like parameters without exposing the direct link of
the file.





On Mon, Apr 27, 2015 at 4:22 PM, Chathura Dilan  wrote:

> Here are the APIs from app manager to subscribe, unsubscribe application
> to a given user or a role
>
> 1. api/v1/apps/mobile/subscribe/tenant/{tenantDomain}/user/{username}
> 1. api/v1/apps/mobile/unsubscribe/tenant/{tenantDomain}/user/{username}
> 1. api/v1/apps/mobile/subscribe/tenant/{tenantDomain}/role/{roleId}
> 1. api/v1/apps/mobile/unsubscribe/tenant/{tenantDomain}/role/{roleId}
>
> You need to send the appId as a form parameter to above APIs additionally
> and all APIs protected by Basic Auth as we have decided earlier.
>
> APIs will return application details if it is successful as follows
>
> {
> platform: "android"
> iconImage: "
> http://192.168.1.12:9763/publisher/api/mobileapp/getfile/uwvOc0yZD4lRuFc.png
> 
> "
> version: "1.5"
> packageName: "com.antivirusforandroid"
> identifier: "com.antivirusforandroid"
> name: "Anti Virus"
> location: "http://
> 
> 192.168.1.12
> 
> :9763/publisher/api/mobileapp/getfile/h88Zf6ZyaaGi801.apk"
> id: "9a3f2a2c-1ebd-46b0-85e6-4c7da3b28ac9"
> type: "enterprise"
> }
>
>
> Note: location details will be only sent with a subscription request.
>
>
>
> On Thu, Apr 23, 2015 at 6:17 PM, Inosh Perera  wrote:
>
>> Hi Dilan,
>>
>> As per the offline discussion we had, I need the input and response
>> details for the endpoint exposed from App for,
>> 1. App install/ uninstall request.
>>
>> Also since App manager does not include the second
>> point described earlier, it is not necessary
>> 2. When the device responds back with the status of the app
>> install/uninstall status to MDM, the end point exposed from App manager to
>> update the status of the operation.
>>
>> Regards,
>> Inosh
>>
>> On Mon, Mar 16, 2015 at 12:10 PM, Chathura Dilan 
>> wrote:
>>
>>> Hi Inosh,
>>>
>>> We need to have an internal discussion regarding finalize the app
>>> uninstall/uninstall and update, because this should be finalized in MDM on
>>> how to accept request. I have created a component[1] in AppM to call MDM
>>> endpoints assuming there is one endpoint from MDM. We can customize it
>>> according to the MDM requirements.
>>>
>>> [1] -
>>> https://github.com/wso2/carbon-appmgt/blob/feature/mdmintegration/components/appmgt/org.wso2.carbon.appmgt.mobile/src/main/java/org/wso2/carbon/appmgt/mobile/wso2mdm/WSO2MDMOperations.java
>>>
>>> On Mon, Mar 16, 2015 at 8:49 AM, Inosh Perera  wrote:
>>>
 Hi Dilan,
 Could you please tell the necessary inputs and the response from App
 manager, for
 1. App install/ uninstall/ reinstall request.
 2. When the device responds back with the status of the app
 install/uninstall/reinstall status to MDM, the end point exposed from App
 manager to update the status of the operation.

 Regards,
 Inosh

 On Fri, Mar 13, 2015 at 4:44 PM, Chathura Dilan 
 wrote:

> Hi,
>
> To access devices from MDM, AppM needs an API from MDM to get list of
> enabled devices for given username, platform and platform version
>
> Sample response from MDM as follows
>
> [
> {
> "id": "12345",
> "platform": "android",
> "model": "Nexus",
> "platform_version": "4",
> "name": "My Device 1",
> "image": "http://192.168.1.40:9763/device.png";,
> "type": "tab"
> },
> {
> "id": "678",
> "platform": "ios",
> "model": "iPhone",
> "platform_version": "8",
> "name": "My iPhone",
> "image": "http://192.168.1.40:9763/device2.png";,
> "type": "phone"
> }
> ]
>
>
>
>
> --
> Regards,
>
> Chatura Dilan Perera
> *(Senior Software Engineer** - WSO2 Inc.**)*
> www.dilan.me
>



 --
 Inosh Perera
 Software Engineer, WSO2 Inc.
 Tel: 0785293686

>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Chatura Dilan Perera
>>> *(Senior Software Engineer** - WSO2 Inc.**)*
>>> www.dilan.me
>>>
>>
>>
>>
>> --
>> Inosh Perera
>> Software Engineer, WSO2 Inc.
>> Tel: 0785293686
>>
>
>
>
> --
> Regards,
>
> Chatura Dilan Perera
> *(Senior Software Engineer** - WSO2 Inc.**)*
> www.dilan.me
>



-- 
*Shanmugarajah (Shan)*
Director, Mobile Architecture,
WSO2, Inc.; http://wso2.com
Email: s...@wso2.com
Mobile : +9448260
Blog: http://shanfour.blogspot.com
___
Architecture mailing list
Architecture@wso2.o

Re: [Architecture] [AppM] [CDM] AppM MDM Integration

[Shanmugarajah Sinnathamby]

Hi Chathura.

In Android , the link is invoked by the agent which downloads the app file
, the agent takes care of the request.

In iOS , the link is sent via the MDM command , which is invoked by the iOS
OS itself to download , which is not a direct link to the .app file but a
manifest file . The request url can have the token along with the request,
but it cannot add any headers programatically.






On Mon, Apr 27, 2015 at 5:02 PM, Chathura Dilan  wrote:

> Hi Shan,
>
> They are direct links but secure connections can be used. Some cases like
> iOS AFAIK it is not possible to send tokens or security headers along with
> the installation request because it is managed by iOS itself. IMO providing
> a direct link will not be a major security issue, since part of the link is
> encrypted.
>
> So only way to make them more secure will be, generating them as one time
> download links. We need to do a proper research on this with real devices,
> so this feature will be support from the next version of app manager if it
> is possible.
>
>
> On Mon, Apr 27, 2015 at 4:43 PM, Shanmugarajah Sinnathamby 
> wrote:
>
>> Hi Dilan,
>>
>> The device will invoke the url to download the apk file , how do we
>> achieve the security .
>> Is there any kind of token ? or its its a direct link .
>>
>> Can we have something like parameters without exposing the direct link of
>> the file.
>>
>>
>>
>>
>>
>> On Mon, Apr 27, 2015 at 4:22 PM, Chathura Dilan 
>> wrote:
>>
>>> Here are the APIs from app manager to subscribe, unsubscribe application
>>> to a given user or a role
>>>
>>> 1. api/v1/apps/mobile/subscribe/tenant/{tenantDomain}/user/{username}
>>> 1. api/v1/apps/mobile/unsubscribe/tenant/{tenantDomain}/user/{username}
>>> 1. api/v1/apps/mobile/subscribe/tenant/{tenantDomain}/role/{roleId}
>>> 1. api/v1/apps/mobile/unsubscribe/tenant/{tenantDomain}/role/{roleId}
>>>
>>> You need to send the appId as a form parameter to above APIs
>>> additionally and all APIs protected by Basic Auth as we have decided
>>> earlier.
>>>
>>> APIs will return application details if it is successful as follows
>>>
>>> {
>>> platform: "android"
>>> iconImage: "
>>> http://192.168.1.12:9763/publisher/api/mobileapp/getfile/uwvOc0yZD4lRuFc.png
>>> <http://localhost:9763/publisher/api/mobileapp/getfile/uwvOc0yZD4lRuFc.png>
>>> "
>>> version: "1.5"
>>> packageName: "com.antivirusforandroid"
>>> identifier: "com.antivirusforandroid"
>>> name: "Anti Virus"
>>> location: "http://
>>> <http://localhost:9763/publisher/api/mobileapp/getfile/h88Zf6ZyaaGi801.apk>
>>> 192.168.1.12
>>> <http://localhost:9763/publisher/api/mobileapp/getfile/uwvOc0yZD4lRuFc.png>
>>> :9763/publisher/api/mobileapp/getfile/h88Zf6ZyaaGi801.apk"
>>> id: "9a3f2a2c-1ebd-46b0-85e6-4c7da3b28ac9"
>>> type: "enterprise"
>>> }
>>>
>>>
>>> Note: location details will be only sent with a subscription request.
>>>
>>>
>>>
>>> On Thu, Apr 23, 2015 at 6:17 PM, Inosh Perera  wrote:
>>>
>>>> Hi Dilan,
>>>>
>>>> As per the offline discussion we had, I need the input and response
>>>> details for the endpoint exposed from App for,
>>>> 1. App install/ uninstall request.
>>>>
>>>> Also since App manager does not include the second
>>>> point described earlier, it is not necessary
>>>> 2. When the device responds back with the status of the app
>>>> install/uninstall status to MDM, the end point exposed from App manager to
>>>> update the status of the operation.
>>>>
>>>> Regards,
>>>> Inosh
>>>>
>>>> On Mon, Mar 16, 2015 at 12:10 PM, Chathura Dilan 
>>>> wrote:
>>>>
>>>>> Hi Inosh,
>>>>>
>>>>> We need to have an internal discussion regarding finalize the app
>>>>> uninstall/uninstall and update, because this should be finalized in MDM on
>>>>> how to accept request. I have created a component[1] in AppM to call MDM
>>>>> endpoints assuming there is one endpoint from MDM. We can customize it
>>>>> according to the MDM requirements.
>>>>>
>>>>> [1] -
>>>>> https://github.com/wso2/carbon-appmgt/blob/feature/mdmintegration/components/app

Re: [Architecture] [CDM-Framework/MDM] Compliance monitoring for devices

[Shanmugarajah Sinnathamby]

Hi Prabath,

The architecture might not fit for all the platforms. It might have to be
based on the platform MDM communciation.
iOS MDM device communication is agentless based (communciation is directly
between the OS and the backend server) , Android is based on Developer
built Agent Application and Windows is based on System Agent Application.
Currently, IoT devices are based on Developer built Agent Application. CPE
devices are agentless based

For Agent based MDM, policy monitoring can happen from the server or from
the client agent itself.
Windows Phone has both mode of communication, you can push or make the
deivce to poll at regular intervals (push is available from 8.1). iOS is
purely based on push notification.
So notifying the deivce is also another criteria for deciding how the
device policy can be monitored.

Like enrollment is different for different platforms, device policy
monitoring can be different. The processing part can be generic.







On Tue, Jun 23, 2015 at 3:29 PM, Prabath Abeysekera 
wrote:

>
> On Tue, Jun 23, 2015 at 3:27 PM, Prabath Abeysekera 
> wrote:
>
>> Hi Everyone,
>>
>> I'm currently in the middle of adding the finishing touches to $Subject
>> for MDM/CDM-Framework. Shown below is the design I've come up with for the
>> same. Thought of sharing with a wider community, for feedback.
>>
>>
>> I believe, the diagram itself is pretty self explanatory. ​In its design,
>> we have a separate web service exposed at the CDM-Framework/MDM GW layer,
>> which directs all monitoring traffic to CEP/BAM for analysis. The incoming
>> data would then be validated upon pre-configured policies and eventually
>> the MDM is notified of the status of policy compliance. In response, MDM
>> would enforce the decisions depending on an applicable action configured
>> upon compliance policy violations.
>>
>> Please do let me know your feedback, should the design be changed.
>>
>> Cheers,
>> Prabath
>> --
>> Prabath Abeysekara
>> Technical Lead
>> WSO2 Inc.
>> Email: praba...@wso2.com
>> Mobile: +94774171471
>>
>
>
>
> --
> Prabath Abeysekara
> Technical Lead
> WSO2 Inc.
> Email: praba...@wso2.com
> Mobile: +94774171471
>



-- 
*Shanmugarajah (Shan)*
Director, Mobile Architecture,
WSO2, Inc.; http://wso2.com
Email: s...@wso2.com
Mobile : +9448260
Blog: http://shanfour.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SCEP & Identity Server (was: Re: Mobile Device Management Architecture)

[Shanmugarajah Sinnathamby]

Hi Prabath ,

Currently SCEP server is within the MDM domain itself . Where validation
will be done based on the user challenge before it gets passed to it. The
validation part is not done.
Also there is a performance issue in the time taken enroll a device ,
Mayuran is working on that along with the validation.



Thanks,
-Shan

On Sun, Aug 4, 2013 at 1:38 PM, Prabath Siriwardena wrote:

> Hi Dilshan,
>
> Have we considered passing the SCEP requests from the devices through the
> MDM and validate those.. There is a separate mail on that..
>
> Thanks & regards,
> -Prabath
>
>
> On Sun, Aug 4, 2013 at 10:11 AM, Dilshan Edirisuriya wrote:
>
>> Yes Prabath our MDM needs not to work as a SCEP server. Right now its a
>> separate WEBRick web server and the code is written in Ruby. SCEP server
>> can be any third party server like EJBCA etc. I had a offline discussion
>> with Azeez and came into a conclusion that the SCEP server part needs to be
>> separated out to a web app written in Java. So any time it can be replaced
>> with anything. Ideally which I believe this part needs to be handle by IS
>> and MDM only communicate with it through the information provided at the
>> deployment time.
>>
>> Regards,
>>
>> Dilshan
>>
>>
>> On Sun, Aug 4, 2013 at 7:09 AM, Prabath Siriwardena wrote:
>>
>>> Just had a look at how this works with iOS [1]..
>>>
>>> I may be totally wrong (please correct me in that case) - I just went
>>> through the doc quickly..
>>>
>>> In the Response from the MDM - it has the following.. Which in fact
>>> giving details to connect to a different SCEP server.. so our MDM needs not
>>> to work as a SCEP server..
>>>
>>> 
>>> 
>>> PayloadContent
>>> 
>>> URL
>>> https://scep.example.com/scep
>>> Name
>>> EnrollmentCAInstance
>>> Subject
>>> 
>>> 
>>> 
>>> O
>>> Example, Inc.
>>> 
>>> 
>>> 
>>> 
>>> CN
>>> User Device Cert
>>> 
>>> 
>>> 
>>> Challenge
>>> ...
>>> Keysize
>>> 1024
>>> Key Type
>>> RSA
>>> Key Usage
>>> 5
>>> 
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>> [1]:
>>> http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/iPhoneOTAConfiguration.pdf
>>>
>>>
>>> On Sun, Aug 4, 2013 at 6:36 AM, Prabath Siriwardena wrote:
>>>


 On Sat, Aug 3, 2013 at 9:04 PM, Sanjiva Weerawarana 
 wrote:

> Dilshan & Prabath, should the SCEP server code ship with IS by
> default?
>
> Prabath I remember a long discussion about certificate issuing and
> distribution 3-4 years ago but don't think we ended up implementing yet ..
> is this a lightweight solution?
>

 Yes.. we didn't make any progress with the CA implementation..

 SCEP server plays the middle-man role in enrolling and getting a
 certificate to a network device (which basically does not have any account
 with the CA).

 SCEP server will know how to talk to a CA (could be the existing
 cooperate CA) and gets the certificate..

 My understanding is MDM needs not to be a SCEP server (please correct
 me if not).. It only has to know how to talk to a SCEP server.. (which may
 be IS, EJBCA or Microsoft CA).

 Mobile devices, when getting registered with the MDM, will get a
 profile with all the details to connect to the SCEP server... and these
 devices will connect to the SCEP server directly and do the enrollment..
 The role of MDM is to embed the OTP and the server URL of the SCEP server
 in to the profile...

 Thanks & regards,
 -Prabath


>
> Dilshan have u guys already implemented it?
>
> Sanjiva.
>
> On Wed, Jul 31, 2013 at 9:01 PM, Dilshan Edirisuriya  > wrote:
>
>> Hi,
>>
>> Attached is the architecture of mobile device management. The MDM
>> build is compiled on top of carbon by using necessary features. Build
>> consist of these layers modules/components.
>>
>> 1) MDM web console - MDM Jaggery app where you have the MDM core
>> functionality.
>>
>> 2) MDM admin console - This is for creating tenants and admins. At
>> present this is done via carbon admin console.
>>
>> 3) Public store  -  Public store Jaggery app.
>>
>> 4) Publisher - Publisher Jaggery app.
>>
>> 5) Store admin console - Admin console for store.
>>
>> 6) iPhone interface - This will run the SCEP server[1] which is
>> needed for iPhone provisioning.
>>
>> 7) Android interface - GCM related functionality goes here.
>>
>> 8) User module - User authentication, register, roles etc. will be
>> handled here. For this we will be using WSRequest in Jaggery or directly
>> calling the OSGI bundle from Jaggery.
>>
>> 9) Tenant management module - Tenants will be handled in this module.
>>
>> 10) Configuration management module - MDM related configurations.
>>
>> 11) Security module - SAML based login etc.
>>
>> 12) Device modul

Re: [Architecture] SCEP & Identity Server (was: Re: Mobile Device Management Architecture)

[Shanmugarajah Sinnathamby]

Hi Prabath ,

The challenge is a random number generated and associated with a user and
device. So when the SCEP request hits in, we check the Challenge and the
associated user device and a flag is set.
Also this gives a flexibility for the user to enroll 1 or more device,
since the challenge is for the device.

Lets say the challenge is stolen by another user or same user, if he tries
to get the certificate using the same challenge, there is a validation
against the user and device. Do you think this can help us to secure ? .
If not what is the best method to overcome the SCEP vulnerability.





On Mon, Aug 5, 2013 at 10:39 AM, Prabath Siriwardena wrote:

> I guess user challenge it self is not enough.. We also need to validate
> the SCEP request..
>
> Thanks & regards,
> -Prabath
>
>
> On Mon, Aug 5, 2013 at 10:32 AM, Shanmugarajah Sinnathamby 
> wrote:
>
>> Hi Prabath ,
>>
>> Currently SCEP server is within the MDM domain itself . Where validation
>> will be done based on the user challenge before it gets passed to it. The
>> validation part is not done.
>> Also there is a performance issue in the time taken enroll a device ,
>> Mayuran is working on that along with the validation.
>>
>>
>>
>> Thanks,
>> -Shan
>>
>> On Sun, Aug 4, 2013 at 1:38 PM, Prabath Siriwardena wrote:
>>
>>> Hi Dilshan,
>>>
>>> Have we considered passing the SCEP requests from the devices through
>>> the MDM and validate those.. There is a separate mail on that..
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>
>>> On Sun, Aug 4, 2013 at 10:11 AM, Dilshan Edirisuriya 
>>> wrote:
>>>
>>>> Yes Prabath our MDM needs not to work as a SCEP server. Right now its a
>>>> separate WEBRick web server and the code is written in Ruby. SCEP server
>>>> can be any third party server like EJBCA etc. I had a offline discussion
>>>> with Azeez and came into a conclusion that the SCEP server part needs to be
>>>> separated out to a web app written in Java. So any time it can be replaced
>>>> with anything. Ideally which I believe this part needs to be handle by IS
>>>> and MDM only communicate with it through the information provided at the
>>>> deployment time.
>>>>
>>>> Regards,
>>>>
>>>> Dilshan
>>>>
>>>>
>>>> On Sun, Aug 4, 2013 at 7:09 AM, Prabath Siriwardena 
>>>> wrote:
>>>>
>>>>> Just had a look at how this works with iOS [1]..
>>>>>
>>>>> I may be totally wrong (please correct me in that case) - I just went
>>>>> through the doc quickly..
>>>>>
>>>>> In the Response from the MDM - it has the following.. Which in fact
>>>>> giving details to connect to a different SCEP server.. so our MDM needs 
>>>>> not
>>>>> to work as a SCEP server..
>>>>>
>>>>> 
>>>>> 
>>>>> PayloadContent
>>>>> 
>>>>> URL
>>>>> https://scep.example.com/scep
>>>>> Name
>>>>> EnrollmentCAInstance
>>>>> Subject
>>>>> 
>>>>> 
>>>>> 
>>>>> O
>>>>> Example, Inc.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> CN
>>>>> User Device Cert
>>>>> 
>>>>> 
>>>>> 
>>>>> Challenge
>>>>> ...
>>>>> Keysize
>>>>> 1024
>>>>> Key Type
>>>>> RSA
>>>>> Key Usage
>>>>> 5
>>>>> 
>>>>>
>>>>> Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>> [1]:
>>>>> http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/iPhoneOTAConfiguration.pdf
>>>>>
>>>>>
>>>>> On Sun, Aug 4, 2013 at 6:36 AM, Prabath Siriwardena 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Aug 3, 2013 at 9:04 PM, Sanjiva Weerawarana >>>>> > wrote:
>>>>>>
>>>>>>> Dilshan & Prabath, should the SCEP server code ship with IS by
>>>>>>> default?
>>>>>>>
>>>>>>> Prabath I remember a long discussion about certi

Re: [Architecture] SCEP & Identity Server (was: Re: Mobile Device Management Architecture)

[Shanmugarajah Sinnathamby]

Hi Prabath,

Hope u had a look at this

http://www.youtube.com/watch?v=SfMeKnch3YA



On Mon, Aug 5, 2013 at 1:41 PM, Shanmugarajah Sinnathamby wrote:

> Hi Prabath ,
>
> The challenge is a random number generated and associated with a user and
> device. So when the SCEP request hits in, we check the Challenge and the
> associated user device and a flag is set.
> Also this gives a flexibility for the user to enroll 1 or more device,
> since the challenge is for the device.
>
> Lets say the challenge is stolen by another user or same user, if he tries
> to get the certificate using the same challenge, there is a validation
> against the user and device. Do you think this can help us to secure ? .
> If not what is the best method to overcome the SCEP vulnerability.
>
>
>
>
>
> On Mon, Aug 5, 2013 at 10:39 AM, Prabath Siriwardena wrote:
>
>> I guess user challenge it self is not enough.. We also need to validate
>> the SCEP request..
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Mon, Aug 5, 2013 at 10:32 AM, Shanmugarajah Sinnathamby > > wrote:
>>
>>> Hi Prabath ,
>>>
>>> Currently SCEP server is within the MDM domain itself . Where validation
>>> will be done based on the user challenge before it gets passed to it. The
>>> validation part is not done.
>>> Also there is a performance issue in the time taken enroll a device ,
>>> Mayuran is working on that along with the validation.
>>>
>>>
>>>
>>> Thanks,
>>> -Shan
>>>
>>> On Sun, Aug 4, 2013 at 1:38 PM, Prabath Siriwardena wrote:
>>>
>>>> Hi Dilshan,
>>>>
>>>> Have we considered passing the SCEP requests from the devices through
>>>> the MDM and validate those.. There is a separate mail on that..
>>>>
>>>> Thanks & regards,
>>>> -Prabath
>>>>
>>>>
>>>> On Sun, Aug 4, 2013 at 10:11 AM, Dilshan Edirisuriya 
>>>> wrote:
>>>>
>>>>> Yes Prabath our MDM needs not to work as a SCEP server. Right now its
>>>>> a separate WEBRick web server and the code is written in Ruby. SCEP server
>>>>> can be any third party server like EJBCA etc. I had a offline discussion
>>>>> with Azeez and came into a conclusion that the SCEP server part needs to 
>>>>> be
>>>>> separated out to a web app written in Java. So any time it can be replaced
>>>>> with anything. Ideally which I believe this part needs to be handle by IS
>>>>> and MDM only communicate with it through the information provided at the
>>>>> deployment time.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Dilshan
>>>>>
>>>>>
>>>>> On Sun, Aug 4, 2013 at 7:09 AM, Prabath Siriwardena 
>>>>> wrote:
>>>>>
>>>>>> Just had a look at how this works with iOS [1]..
>>>>>>
>>>>>> I may be totally wrong (please correct me in that case) - I just went
>>>>>> through the doc quickly..
>>>>>>
>>>>>> In the Response from the MDM - it has the following.. Which in fact
>>>>>> giving details to connect to a different SCEP server.. so our MDM needs 
>>>>>> not
>>>>>> to work as a SCEP server..
>>>>>>
>>>>>> 
>>>>>> 
>>>>>> PayloadContent
>>>>>> 
>>>>>> URL
>>>>>> https://scep.example.com/scep
>>>>>> Name
>>>>>> EnrollmentCAInstance
>>>>>> Subject
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> O
>>>>>> Example, Inc.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> CN
>>>>>> User Device Cert
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Challenge
>>>>>> ...
>>>>>> Keysize
>>>>>> 1024
>>>>>> Key Type
>>>>>> RSA
>>>>>> Key Usage
>>>>>> 5
>>>>>> 
>>>>>>
>>>>>> Thanks & regards,
>>>>>> -Prabath
>>>>>>
>>>>>> [1]:
>>>>>> http://developer.apple.com/library/ios/documentation