Andy Zmolek, Director, Business Development, Enterproid New techniques for separating enterprise apps and data on employee-owned (or corporate-owned) mobile devices give the enterprise confidence that native mobile apps can be both secure and accessible. Explore how MAM, virtualization and other emerging dual-persona solutions can improve the mobile SSO experience when native mobile apps leverage the container model to construct a shared identity context.

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

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

3. 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. 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

5. …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. 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. 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

8. 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. 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

10. 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!

11. 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. 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. 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. 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. 16!
ANDROID ACCOUNT MANAGER = SSO?
OAuth 2.0 on Android through Google APIs or Custom Account Types

17. 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!

18. 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. 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.

20. 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?

21. 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

22. 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!

23. 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!