Identity Management Plays a Key Role in Mobile Device Management (MDM) Arrow to Content

April 30, 2013 | Leave a Comment

By: Dan Dagnall, Chief Technology Strategist, Fischer International Identity

As BYOD and other mobile device related initiatives take hold, sooner rather than later, identity management will once again be considered as an enforcement mechanism; and rightly it should.

Identity and access management (IAM) has grown up over the years.  Its early beginnings were in metadata management and internal synchronization of data to/from target applications.  Lately it seems like one cannot roll out a new technology or service without considering the effect IAM will have on the initial roll-out, as well as ongoing enforcement of security, access, and policy related evaluations.

IAM is becoming the hub for all things security and so it should be for mobile device management.  MDM provides an administrative interface for managing server-related components, as well as self-service interfaces and over-the-air provisioning.  All of these components are key to a successful BYOD strategy, and all of these components should consider IAM as the authority in terms of the overall decision making process.

  1. When to provision the device (including the association of the device to the end user)
  2. When to lock/wipe the device
  3. How to enable users the ability to request apps for download and which apps they qualify for.
  4. How to allow users to leverage the device for multi-factor authentication

When to provision the device (including the association of the device to the end user)

As a user’s identity is created within an organization, MDM actions are needed to secure the end point device and associate that device with the end user for BYOD initiatives.  MDM technology provides for the ability to provision apps to the device.  In the IAM world, the same exercise occurs when a new user is detected and evaluated against access policies to validate and define the user’s identity in terms of application access and the exact permissions the user’s identity is to be granted.

Given that IAM should be looked to and leveraged as the authority over mobile device provisioning, organizations in the above scenario should not re-create the wheel. Rather, they should consider extending their existing IAM resource pool (i.e., those items controlled by IAM and associated policies defined within IAM) to include MDM servers, administrators, and end user device management.   I am not saying that IAM should consider replicating or mirroring the same functionality granted by MDM servers and management consoles, but I am advocating that those interfaces and servers fall under the umbrella of enforcement attributed to what IAM already does for your organization. In the IAM world, this consists of an integration component to enable external enforcement of MDM-related policies and actions originating from the IAM stack.

When to lock/wipe the device

Blocking users from accessing their applications (for multiple reasons) is a fundamental attribute of IAM.  There is no need to deploy new MDM technologies or write new integration points or, again, re-create the wheel when it comes to disabling or locking a user out of an application on the device, or the device itself.  In many cases, there are automated processes in place in the identity side that will immediately disable or lock a user out of the system if certain criteria are met.  For instance a termination event will initiate the disabling (or locking) actions.  So instead of focusing on disabling everything else and then leveraging an MDM interface to push actions to the mobile device, those termination actions (or disabling actions) should be driven from within the context of IAM.

How to enable users the ability to request apps for download and which apps they qualify for Requesting access in the form of applications or associated permissions is not new to IAM either.  MDM brings the concept of controlling which apps a user is able to download and run on their device.  This is a fundamental component of IAM (evaluate a user, and qualify for a specific application set and specific permissions based on the users role(s) within the organization.  Extending this type of self-service capability to users via IAM, instead of a separate solution strictly for MDM can potentially cost your organization much less.  IAM solves this problem very well by limiting which applications a user is able to request by enforcing access and permissions related policies at log in.  Proper identity & access management will evaluate the user at log in time and determine what he/she is able to request.  This concept is not new to IAM, and extending it to include enforcement of [mobile] apps can save you time and money.

How to allow users to leverage the device for multi-factor authentication

This new(er) trend places the mobile device in the spotlight more than any other mentioned in this article.  The requirement of organizations to leverage the mobile device as a second form of authentication (and identity verification) ties the device, BYOD and mobile device management directly to IAM.  Organizations developing an MDM strategy and deploying a solution must consider the effects of identity & access related policies while developing their MDM strategy.  Organizations that look to their existing IAM solution for answers regarding MDM management and enforcement will find that their IAM stack is a viable option for securing mobile devices.  In many cases extending the IAM solution to encompass the new MDM components will take work, however integration between different platforms is something IAM vendors (or developers) do very well, and lack of integration with your new MDM platform should not be a reason to forego merging IAM and MDM.

Bottom line:

Overall, identity and access management will play an increasingly important role regarding enforcement of MDM policy, as well as authorization of MDM admins to take actions against end user mobile devices.  If your organization has an extensive IAM solution in place, I strongly suggest you consider placing most (if not all) enforcement, provisioning, de-provisioning, and device identification (i.e. associating a device to a user) in the capable hands of your IAM solution.  The project may look a lot different than you anticipated, but you’ll find that IAM can provide many more answers than questions when it comes to how you should roll out your new MDM / BYOD strategy.

 

Related CSA Resources Arrow to Content

Comments:

Be the first to comment on this post!

Leave a Comment




Page Dividing Line