MOBILE IDENTITY: DIVIDE AND CONQUER Andy Zmolek – Enterproid @zmolek

Click to edit Master subtitle style PART 1: MOBILE EVOLUTION What do BYOD and other mobile trends demand from enterprise IT?

ENTERPRISE MOBILITY EVOLUTION TREND (INCLUDING BYOD) Mobile paradigm shift - both IT and employees treat mobile devices differently now

V1.0

V2.0

SECURE PERSONA & VIRTUALIZATION

MOBILE APPLICATIONS MANAGEMENT (MAM)

MOBILE DEVICE MANAGEMENT (MDM)

SECURE MESSAGING

V1.5

3!

4!

SERVER/DEVICE MINDSET •  Employees use only enterprise assets to

connect to enterprise services; personally-owned devices were the exception

•  Most IT services are limited to specific approved devices and physical locations

•  IT control (or wipe) for the whole device

•  IT focus on device lifecycle support which is strongly bound to IT services

•  Corporate data never allowed on employee-owned devices unless device is under IT control

•  User experience rarely a critical factor for the success of new service launches

CLOUD/MOBILE MINDSET •  Employees use only enterprise assets to

connect to enterprise services; personally-owned devices were the exception

•  Most IT services are limited to specific approved devices and physical locations

•  IT control (or wipe) just enterprise content

•  IT focus on service lifecycle support which is only loosely bound to devices

•  Corporate data allowed on devices not owned by the enterprise, as long as data itself remains under enterprise control

•  Overall user experience critical to successful new IT service launch

IT MINDSET SHIFTS AS ENTERPRISES MOVE TO CLOUD+MOBILE Endpoint-oriented MDM concepts need adjustment to function in BYOD world

…NOW EVERYONE HAS A STAKE

CIO

“Can we initiate a corporate-wide BYOD program in the next month or two?”

CIO

“Do we have a business continuity program for BlackBerry?”

EMPLOYEES

“Device-level passcode! Can’t we just use passwords for corporate data?”

EMPLOYEES

“Can you really wipe my whole device? And can IT really see everything?!”

LEGAL

“The company is LIABLE for anything we manage, including personal apps.”

HR

“BIG employee concerns about privacy and Europe believes we violate privacy laws.”

CFO

“Mobile costs are out of control. Can you trim by 50% or so?”

CONTROLLER

“Our mobile spend is too high, can you confirm work versus personal usage?”

CIO

“The security and compliance folks are in my office…”

5!

6!

FUNDAMENTAL CHALLENGES FOR IT IN A BYOD WORLD A go-forward mobile identity solution needs to align with these realities

Support at Rapid Scale •  Mobile deployments

rapidly grow 2-3x of the current user base

•  Salable, on-premise infrastructure is expensive and resource intensive

•  Support costs for mobile are inflating rapidly

Employee Concerns •  User Privacy •  Device Wipe •  Use Constraints •  Whole-device passcode

IT Security Worries •  Device Fragmentation •  Secure Connectivity •  Secure apps, distribution,

limiting apps (malware) •  Too many endpoint

management solutions (PC, laptop, MDM, TEM etc.)

2013

2000

2006

7!

If I buy the device, shouldn’t I have the final say before you wipe my personal data? •  European privacy laws have already forced this issue in parts of the world Complex passcodes for mobile devices + short timeouts = horrible UX, many bad side effects •  If I own the device, shouldn’t I have a say on how to protect my personal data? •  Personal phone calls from a locked phone still require an enterprise-class credential •  My children require the device passcode so they can play games on my phone…BUT

I can’t keep them out of my work email app once they’re on my phone

Device-level enterprise services fit poorly •  VPN not appropriate for personal apps •  Enterprise identity not intended for use

by personal apps but can’t be separated •  Encrypted filesystem pointless if I load

malware-infected personal apps

IT shouldn’t need to know or care what I do with my device on my own time, right?

PERSONAL DEVICE + ENTERPRISE USE = DEVICE-LAYER CLASH IT over-reliance on device-level policy creates more problems than it solves

USERS PREFER TO LET IT PROTECT BUSINESS APPS SEPARATELY Choice of controls on personal side for device protection; IT policy applied just to work access

PERSONAL ENTER PASSCODE WORKSPACE

8!

9!

USER SELECTS DEVICE-LEVEL SECURITY FOR PERSONAL NEEDS IT standards apply only to work applications – employee gets to choose how to protect the rest

DUAL PERSONA IS FOUNDATIONAL Separate and Secure Dual Personas

• Data security • Enterprise apps and services • Easy to manage and control

• Native user experience • Choice of device, services • Freedom and privacy

10!

Click to edit Master subtitle style PART 2: MOBILE SSO IN A BYOD WORLD What will mobile devices demand from enterprise identity and SSO solutions

13!

THE ENTERPRISE OBSESSION WITH DEVICE PASSCODES And why it’s such a distraction for mobile identity (and mobile SSO)

Complex device-unlock passcodes and device-wide encryption give the illusion of protecting enterprise data but force IT into a reactive security posture •  Device becomes the enterprise security perimeter •  Personal apps allowed by default, with no line of

demarcation between personal and business use •  Personal app blacklisting happens only after the

threat has been identified (which may be well after the damage has been done)

Scope of enterprise identity services highly dependent on OS-level keychain or account management services •  Variation between OS-level services is nontrivial •  Reliance on OS-level passcode to protect identity •  Adding SSO functionality forces ugly tradeoffs between

convenience of device-level credentials (particularly when offline) and use of standardized desktop-oriented credentials

How much transitive trust of device passcode is appropriate for mobile SSO use cases?

14!

OUR SSO DILEMMA, COURTESY OF INIGO MONTOYA: Mobile SSO is conceivable in so many different ways – what do we really intend?

“YOU KEEP USING THAT TERM ‘MOBILE SSO’”"

“I DON’T THINK IT

MEANS WHAT YOU THINK IT MEANS”"

15!

•  D-facto “SSO” happens: look at how

smartphones and tablets control authentication today – often the device passcode is used to unlock device keychain/keystore holding credentials for related SaaS services

•  iOS specifically ties app access to the state of device unlock, even on iOS 7; passcode/credential relationship is often less direct in other mobile platforms

•  Every modern mobile OS has an “Accounts” concept that ties identity to the device for things like email access – very common for consumer identity (facebook, Google, etc.)

•  Individual mobile apps often allow end-user to sign-in once and get a token to be re-used for continuous mobile device access from that point forward. Only the mobile device passcode remains to protect from unauthorized access, assuming it’s been set in the first place.

MOBILE DEVICE PASSCODE = SSO? The “SSO” that happens by default

16!

ANDROID ACCOUNT MANAGER = SSO? OAuth 2.0 on Android through Google APIs or Custom Account Types

ANDROID ACCOUNT MANAGER = SSO? (CONTINUED) Drilling deeper into Android Account Manager

•  Oauth 2.0 support is baked in •  Account Manager is not a Keychain – use it only to store tokens •  Enterprise and consumer identities are mixed – scoping enterprise identity is not automatic •  Custom Account Types are hard to do when adopting apps aren’t known up front

–  Account Manager requires SyncAdapter and Content Provider to be fully coordinated

17!

IOS KEYCHAIN = SSO?

18!

Will the new Kerberos features in iOS7 “solve” Mobile SSO?

iOS Keychain was originally set up to store credentials for a single app or group of apps from a single developer •  An enterprise that delivered their own applications could use

the keychain to assist with SSO but could not extend keychain to apps by 3rd party developers

iOS 7 introduces two new concepts to the Keychain: •  iCloud keychain for storing credentials across devices •  Apple’s new Kerberos-based SSO solution (requires

MDM-managed device with enterprise app provisioning; each app must use NSURL APIs supplied by Apple)

Full APIs for the MDM-side of the new iOS 7 approach are expected some time this month Apple has left it up to the app developers to envision how SAML or OAuth might be used in conjunction with their new SSO scheme.

19!

DEVICE (OR CONTAINER) CERTIFICATES AND IDENTIFIERS = SSO? Presentation of an alternative credential or identifier can be used in place of authentication

Certificates can be an excellent solution to identity assertion when enterprise IT is disciplined •  Avoid temptations to take operational shortcuts in how certificates are provisioned •  Never let the private key of the certificate leave the device (easier said than done)

–  If the certificated is to be stored in the iOS keychain, don’t allow iCloud to copy it –  Android doesn’t have a true keychain – certificates don’t belong in Account Manager

•  Look carefully at the process for authenticating certificate signing requests and pay attention to what credentials are used to generate the certificate. Be sure that transitive trust makes sense when password-based credentials are part of the process.

Certificates stored inside individual apps can’t be directly shared with other apps, so if the intended scope of the certificate is for multiple apps on the device, storing the certificate in the work “container” of a dual-persona solution can protect it from exposure. Unique device identifiers (like UDID, MAC address, IMEI, MEID, etc) are often used similarly to “authenticate” but the application and back-end SaaS service must trust that the OS has not been compromised. And SaaS services should not trust identifier data from 3rd-party apps.

user@enterprise.com P@55w0rd!

20!

•  The most common enterprise mobile application remains email, and the most common protocol for obtaining it is ActiveSync – but it requires a cached password credential

•  If you’ve got to store it (and it has to be reversibly stored to use with ActiveSync), then why not re-use the credential to authenticate to other Microsoft-based enterprise services?

•  Some ActiveSync proxies and gateways can do this transparently for HTTP-based traffic from mobile devices when properly configured (for SharePoint traffic, for instance)

•  Other options include 3rd-party SDKs that enable native mobile apps to bind to Microsoft domains when used with certain MDM agents on devices or at the container level with certain container solutions

ACTIVE DIRECTORY / KERBEROS INTEGRATION Why not present cached ActiveSync Exchange credential to obtain MS-Kerberos tokens?

NATIVE AUTHORIZATION AGENT

21!

When coupled with a container solution, the AZA concept is even more compelling

By introducing an AZA onto the device (or even better: to the enterprise container on that device), native enterprise applications can leverage the AZA for a fully-featured shared SSO •  Rather than each application individually obtaining OAuth tokens for itself, tokens are

obtained by the AZA through mobile web browser (or secure container browser) •  Native applications pass tokens received from the AZA directly to back-end SaaS services

just as their browser-based equivalents

AZA Advantages •  For user, enables an SSO experience for native applications with explicit authentication and

authorization only required for the AZA itself •  For enterprise, provides a centralized control point for application access, tokens issued to

native apps are identical to those used with web apps •  For the app developer, provides easy SSO integration; AZA-based authentication follows

HTML patterns used to obtain application tokens

Additional Advantages of AZA when used with secure container / dual-persona •  Personal use of browser is separate from enterprise browser – no enterprise data leakage •  Enterprise applications under direct control of enterprise IT •  Leverage certificates and container passcode to eliminate manual password input for AZA

itself without impacting personal-side user experience or adding excess risk

CONQUER MOBILE SSO USE CASES WITH CONTAINERIZATION Dual-persona with mobile identity unlocks the best mobile experience overall

Full IT management Highly secure Business deployed apps

Individual privacy & freedom No limitation of functionality Full personal app store access

IT

Employee

22!

DIVIDE NEW YORK. HONG KONG. LONDON." Contact our sales team at: sales@divide.com"

COMPANY CONFIDENTIAL © 2013 Enterproid, Inc. Enterproid, Enterproid Divide and the Divide logo are trademarks of Enterproid, Inc. All other product or company names may be trademarks and /or registered trademarks of their respective owners. While every effort is made to ensure the information given is accurate, Enterproid, Inc. does not accept liability for any errors or mistakes which may arise. Specifications and other information in this document may be subject to change without notice.!

Learn more by visiting: www.divide.com THANK YOU! THANK YOU!