How iOS 7’s new APIs change the game for business

If there’s any company making mobile safe for business but useful for people, it’s Apple. And Apple is making iOS and OS X even safer while remaining truly useful for people in the new content and application management APIs debuting in iOS 7 and OS X 10.9 Mavericks, detailed later in this post. The move will create a huge, positive shift in attitudes about business use of mobile tech, and I daresay PC tech as well, especially as third-party tools and software developers adopt the APIs.

And they will: AirWatch, Centrify, Citrix Systems, Good Technology, MobileIron, MobileSpace, and so on have already announced they will use the technology in their management tools (some are already shipping). In an interesting twist, MobileSpace is also providing similar capability for Android.

[ Galen Gruman describes a smarter approach to mobile security. | Mobile security: iOS vs. Android vs. BlackBerry vs. Windows Phone. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. ]

When Apple adopted Exchange ActiveSync (EAS) and added its own management and security APIs to iOS 4.2 in summer 2010, business joined the mobile revolution. Suddenly, IT could enforce password policies, be confident that on-device encryption was enabled, and even regulate device access to specific Wi-Fi networks, applications, and various services for users where locking down access was a legitimate security need. Over time, Apple has refined those controls in each subsequent iOS version and added many of them to OS X. Google copied the basic APIs for Android, and Samsung enhanced them to be closer to what Apple offers.

Thus, mobile device management (MDM) has become a largely settled issue. It may explain why so many vendors and IT organizations have set their eyes on another fear: loss of control over corporate information, such as email attachments, working documents, and the like. MDM can block access or restrict it to certain apps and network services, but it doesn’t manage the content.

The industry response was a slew of proprietary tools that required developers to adopt vendor-specific APIs and use the vendors’ own management tools or a handful of tools from partners. Few commercial apps risked committing to one mobile application management (MAM) API, and fewer committed to supporting multiple ones. Few IT organizations have been willing to make such a fundamental development commitment either, realizing that embedding proprietary APIs into their own apps locked them to specific vendors in a young, risky market — and we all know how rarely companies rework old apps, as all those still-used ActiveX and Internet Explorer-dependent services attest.

Apple’s new management APIs largely obviate those proprietary tools. If you adopted them or are planning to, pause now. Pay the $100 to become an Apple developer, learn the Apple APIs, and adopt them in your apps, whether they’re for just your business or for public App Store distribution. You can bet that every major mobile management tool will adopt them — and some system management tools will too, as they also work in OS X apps. Apple provides a common set of APIs all apps can use and all management servers can manage. If you need more than this new baseline, then you should consider proprietary APIs available from vendors such as Apperian, Good Technology, and MobileIron that provide richer, multilayer controls on top of the Apple APIs.

In fact, the new Apple APIs should point the way to make Windows PC’s content secure. It’s a dirty secret that for all the alarm bells raised over mobile content “loss,” the real loss has been from PCs for years, and there’s not much one can do about it while keeping them usable. But now Macs can be secured as if they were mobile devices. Perhaps Microsoft will adopt the Apple APIs to make Windows PCs truly securable without compromising usability.

Here are the key content and application management APIs and related capabilities that iOS 7 and OS X Mavericks bring to the table. Apple of course has documentation on much of it in its developers website (you need a developer account to view these) as well as a public overview for IT.

Managed Open In

The Open In facility is how iOS exposes content from one app to another. In iOS, there is no shared file system, which prevents malware attacks and keeps apps’ content stores separate from other apps. Instead, apps specify what file formats they both support and will accept from other apps. Users see this as the Share sheet pane of compatible apps when they use the Share button or other Open In trigger. The current app then calls the selected app and offers to send it the selected file. This is how, for example, you move a file attachment from Mail into GoodReader or Dropbox, or from Dropbox to Apple Pages or Google Quickoffice.

A new API in iOS 7 and OS X Mavericks lets you specify which apps may be sent Open In calls — essentially, whitelisting apps that can accept data from the apps you provision or manage. The management is at the account level, so all accounts (including Mail and Calendar) and apps provisioned by the corporation follow the Open In policy set for that account. It’s important to understand that managed Open In is binary: All managed apps (those provisioned by the company) have the same set of Open In policies, and all unmanaged apps (those provisioned by the user from the App Store) have none of your Open In policies applied, notes Ojas Rege, vice president of startegy at MobileIron.

Where the new managed Open In approach falls short is when an app has both personal and business uses, as many commercial apps do. The Open In policy applies to any and all documents in an app, as there is no way outside of account-based apps like Mail to know whether the data is corporate or personal. I’ve urged Apple and its competitors create a more granular information management standard I’ve dubbed InfoTrust.

iOS cannot run multiple instances of an app, so you can’t have an unmanaged personal copy and a managed work copy, notes Dan Dearing, vice president of marketing at MobileSpaces. (Android doesn’t have this single-instance  limitation.) This is the Achilles’ heel of Apple’s new application management approach: Apple really should have taken the iOS 7 opportunity to allow at least two instances, so users could run separate instances of apps like Dropbox, Box, Quickoffice, iWork, and so on, one managed by their workplace and one for personal use.

Until that’s possible, it will be hard for IT to apply managed Open In to common apps like Quickoffice and Pages, as there can only be one instance in iOS; the app either is managed and thus usable only for business, or it is unmanaged and used only for personal needs. Furthermore, if a device already has a personal copy of an app for which you want to apply managed Open In, its user has to remove the app, then install the corporate-provisioned copy of the app, Rege notes.

One workaround to the single-instance limitation would be to let developers sell one version in the public App Store and another via the corporate App Store, so iOS sees them as separate apps and allows both to be installed on the same device. That means users have to separate mentally the two app versions — not elegant, but perhaps the only realistic method today. This is a scenario where there’s still value in proprietary app-management systems (like Good’s Dynamics and MobileIron’s App@Work) for commercial developers to create separate business and personal versions.

I need to point out that this app collision won’t apply to account-oriented apps like Mail, Notes, Calendar, and Reminders. iOS has long separated the data within accounts in such apps, so it “knows” the data from a corporate Exchange server is not to be commingled with that of your home IMAP provider. That’s why a business can wipe your work email without wiping your personal email. iOS 7 simply makes the corporate accounts linkable to the corporate-provisioned apps (which after all are provisioned through the same management server), so Exchange email’s Open In use can be restricted to specific apps without also restricting Open In from other accounts.

Single sign-in and unified passcode policies

iOS 7 and OS X Mavericks unify storage of and access to sign-in keys, using what’s called the shared keychain, so they can be used by multiple apps and managed via an MDM server. In previous versions of iOS, the internal dev team at a company could use a shared keychain for single sign-in to corporate apps. A developer with a suite of apps could do the same for that suite.

The new Kerberos-based single sign-on facility lets IT federate these shared keychains as well as single apps’ keys, so a common login can unlock all the apps whose passwords have been federated. That single sign-in key is stored by iOS, not by the apps, and managed by your own management server. Most apps don’t need to be recoded to be compatible with single sign-in. But deploying the single sign-on does mean work for IT to make the Kerberos key facility accessible through a VPN rather than over the Internet, notes MobileIron’s Rege.

OS X Mavericks’ passcode policies are now identical to those in iOS 7, so IT can stop worrying about the implementation implications of minor differences in previous versions.

AirPlay, AirPrint, and font management

In iOS only, a new API allows an MDM server to force mirroring to an Apple TV or other AirPlay destination, such as for an iPad used as a kiosk device. iOS devices’ policy payloads can also contain whitelists of allowed AirPlay devices and their passwords, so a company can configure managed devices to automatically connect to corporate conference rooms’ Apple TVs without revealing the access passwords to users. Likewise, you can configure allowable AirPrint destinations (meaning printers).

In both iOS and OS X, policies can now install fonts onto devices, such as to ensure corporate identity consistency.

Per-app VPN and Web content filtering

The new facility in iOS and OS X lets corporate-provisioned apps establish a separate VPN connection, so businesses don’t have to worry about a user opening a device-level VPN connection and having any app running take advantage of it. This also ensures that personal apps’ data don’t go through the corporate VPN, as happens when a device-wide VPN connection is in use. In iOS, the apps need to be configured via a policy to use per-app VPN when they are installed; they can’t be so configured after the fact. Also, your VPN needs to support the per-app feature, so check with your VPN vendor about iOS 7 compatibility, Rege notes.

In iOS only, policies are now available for managing Web content filtering.

Wi-Fi Hotspot 2.0

Both iOS and OS X support the Wi-Fi Hotspot 2.0 standard (aka Passpoint), which is based on the IEEE 802.11u standard and essentially allows automatic roaming across hotspots for those that you have a service subscription for. The new Apple APIs allow its configuration and management.

Encryption management in OS X

Since version 4.2, iOS has always been encrypted at the device level, and there are no controls to disable that encryption. By contrast, use of device encryption (aka FileVault) is optional in OS X. OS X Mountain Lion introduced policies to enable encryption as part of a policy payload, and OS X Mavericks extends that control further. IT can now prevent encryption from being turned off through policies and manage the encryption recovery keys directly. The keys can be managed via a corporate server’s key escrow, instead of through Apple’s own key server. The institutional recovery key can now be rotated at IT’s preferred schedule, via an MDM tool.

Additional iOS policies

On devices running in supervised mode — that is, those issued by a company preconfigured, the familiar BlackBerry approach — there are now APIs for policies on whether users can change account information, whether users can change entries in the Find My Friends app (such as to only track specific colleagues in a workgroup, and to prevent employees from making themselves invisible if their location is being tracked), whether apps may use cellular data or not, whether devices can pair to other Macs, and define allowable services (such as copy or paste) for text selections.

Setting a device to supervised mode no longer requires physically connecting it to a PC or Mac running the Apple Configurator tool; supervision can now be set up at purchase and managed over the air.

For any iOS device, new API restrictions include controls over ad tracking, iCloud Keychain syncing (the unified website password cache shared across all devices on the same account), over-the-air PKI updates, and whether the Wi-Fi and Airplane Mode buttons appear on the lock screen.

Also for all devices, MDM servers can now query whether the mobile hotspot function is enabled (to make the device a Wi-Fi access point for other devices, so they can share a cellular connection), whether Do Not Disturb is active, whether Find My iPhone is enabled, and whether an iTunes account is signed in. New controls include setting a custom lock screen, putting a device in lost mode (so its lock screen displays “if you find me” information), and disabling the hotspot feature.

Device enrollment without touching the device

In addition to these APIs, Apple has created a new protocol for enrollment of supervised devices, so a business can provide iPhones, iPads, Macs, and even Apple TVs preconfigured with the business’s policies — without having to open the box or touch the hardware. Essentially, IT enters the device IDs supplied from the purchase order into an enrollment tool, specifies the policies that apply (such as passwords, allowable networks, VPN settings, app blacklists, and iCloud and iTunes access). Note that this new device enrollment service is only for corporate-owned (supervised) devices, not BYOD ones owned by users.

When a user opens the box and starts up, the device checks into the Apple server, which relays that it is a managed device and refers the device to the business’s management server. The user is asked to sign in using their corporate credentials or separate credentials provided by the company. Upon user login, that corporate server or MDM tool uploads the XML policy payload to the device, which configures it and directs the device to auto-install any apps associated to that user.

If a user wipes the device, the policy payload remains, so it can only be used within those corporate settings unless IT frees the device from the policies (such as when it sells the device to a departing employee) or applies a new set of policies (such as when shifting the device to another user). When policies are updated, so is the device — automatically and silently.

This new device enrollment also does not require the user to have an Apple ID, though the company can allow the user to access personal apps and other services using a personal Apple ID stored on the iOS device or Mac, not in the company server. Thus, the user’s Apple ID is not shared with the business (its hash is stored at the business, so the Apple servers can anonymously associate the corporate users to the user devices). That means personal and corporate information, apps, and even identifiers are kept separate on the same device.

Managing app configuration, state, installation, and revocation

A new MDM-managed capability is called App Configuration and Feedback, which lets IT configure a managed app’s settings via a configuration profile (called a dictionary) and check the configuration state and at each launch or unlock, as well as poll for error messages and usage statistics to aid in troubleshooting. This should help corporate-provisioned apps work as IT intends once installed and help IT support understand a user’s app settings in case of a trouble ticket.

The new app-requested single-app mode lets an app take over the device, not allowing other apps to run. Use cases include kiosks in stores and use of iOS devices for single purposes such as for poll-takers or patient registration. An MDM server can enable or disable this mode, so apps can be in single-app mode for a specific period — such as a testing or lesson app in a school.

The new app-management protocols also let IT specify apps to be installed automatically on iOS devices and Macs, based on the new ability to buy and distribute app licenses rather than individual (per-user) redemption codes. MDM servers can manage which apps are available to whom and which are auto-installed (the others show up in the Purchased pane in the App Store app on the user’s device, available for download if desired).

Licenses to such managed apps can be revoked, so apps no longer automatically become owned by the user, as in the case of redemption codes. (However, content licenses — such as for books — stay with the user and cannot be revoked.) Revoked iOS apps continue to work for a 30-day grace period, and a prompt to buy a noncorporate copy appears. (You’ll need to manage access to information separately, such as by disabling VPN or email access using their own policies.) Revoked OS X apps stop working immediately, quitting on launch. For this to work, managed apps need to check their receipt status.

These licenses and their installation management are available for apps in the Apple corporate app store, aka the App Store Volume Purchase Program, and do not apply to apps in the public App Store — Apple considers those to be personal apps that companies have no rights over. It’s a clear separation: Even though there’s one user interface, iOS and OS X tracks which apps and content come from the corporate app store, Exchange or other server, and any management servers, then provides IT control over those. Whatever the user buys from the public App Store or accesses from his or her own email and other accounts belongs to that user — including the Apple ID.

That principle has been in iOS since version 4.2, but the new APIs and protocols extend it more deeply into the application and content domains. As a result, most organizations’ data protection and app isolation needs should be supported without relying on specific vendors’ management tools and APIs. IT can use a broader variety of corporate apps without being locked in to specific management vendors — and thus should be able to get control over more apps than is possible today. Users avoid the hassle of switching between personas, a clunkier approach adopted by BlackBerry 10’s Balance feature, Samsung’s Knox protocol, General Dynamics’ Android version, and Android tools such as Enterproid’s two-year-old Divide. After all, who needs clunky?

Oh, and about TouchID

Finally, the new iPhone 5s has a fingerprint reader on its Home button that saves the user from entering the unlock password or iTunes Store password. This TouchID feature is a surrogate way to enter a password — the user still has a traditional password that the fingerprint reader issues when it recognizes the user’s fingerprint. TouchID is not available to other apps, just for unlocking and the iTunes Store. And its fingerprint hash is stored only on the device, so is not sent to Apple or anywhere else.

Ignore all the talk about biometrics and the pros and cons of that security technique. For now, TouchID is simply a faster way to enter a password to unlock a device or confirm an iTunes Store account. It’s great for users but has no other implications for apps or IT.

This article, “How iOS 7’s new APIs change the game for business,” was originally published at InfoWorld.com. Read more of Galen Gruman’s Smart User blog. For the latest business technology news, follow InfoWorld.com on Twitter.