cis14: providing security and identity for a mobile-first world

Security & Identity for a Mobile-First World Vijay Pawar

2 MobileIron Confidential

Traditional Desktop

Login with Enterprise Identity (AuthN)

Browser or Native Apps Access & SSO

Applications based on Identity(AuthZ)

Pre-registered using IAM

Authentication to Applications: Desktop

Password

Tokens

Biometrics

Smartcards

Certificates

Authentication: Traditional Desktops

Password

Tokens

Biometrics

Smartcards

Certificates SECURITY

USABILITY + DEPLOYMENT

Mobile

Login with pin (AuthN)

Native App Access

Applications from Enterprise App Store based on Identity(AuthZ)

Pre-registered using EMM

Applications based on Identity(AuthZ)

Browser Access & SSO

Authentication to Applications: Mobile

Leverage Same Factors

Password

Tokens

Biometrics

Smartcards

Certificates

Auth Factors

Passwords •  Bad UX: Typing long

passwords, fat-fingering

Biometrics •  Good UX (Fingerprint, facial

(early stage), voice)

Tokens •  Bad UX: Carry along or on

same device (reduces security)

SmartCards •  Bad UX: Adding additional

hardware

EMM Certificate Support

Ease in Certificate Delivery

High Security (MITM-proof)

Multiple Usage (VPN, Wi-Fi, Apps, Browser)

Good UX

Authentication: Mobile Devices

Password

Tokens

Biometrics

Smartcards

Certificates SECURITY

Tokens

Biometrics

Certificates

Smartcards

Password

Identity Verified

Authorized to Access App

Authorization to Applications: Desktop

Access •  Based on AD Group •  Context

•  Network •  Time

In App Access •  Typically handled inside App

Authorization Technology: Desktop

SaaS •  Standards (Federation) •  Proprietary (WAM) •  Password Mgr •  E-SSO

Native •  E-SSO

Authorization: Traditional Desktops

Password Mgr

Federation SECURITY

Authorization to Applications: Mobile

Access •  Based on AD Group •  Context

•  Network •  Time •  Device Posture •  Location •  App Inventory

In App Access •  Typically handled inside App

Authorization Technology: Mobile

SaaS •  Standards (Federation) •  Proprietary (WAM) •  Password Mgr

Native •  E-SSO •  Wrap/SDK

Authorization: Mobile Apps

Password Mgr

Federation SECURITY

Wrap/SDK

Recommendations: Cloud Apps Authorization

Support Federation Standards

If Username/Password Access • Restrict by IP address for All Applications (ex. email &

content)

IDP or SaaS providers to use Device Context

Future: Authorization: Mobile Apps

Password Mgr

Federation SECURITY

Wrap/SDK

Identity Verified

Multiple Applications

Need Single Sign-On

SSO to Applications: Desktop

SaaS •  Standards (Federation) •  Proprietary (WAM) •  Kerberos •  Certificates •  Password Mgr •  E-SSO

Native •  Kerberos •  Certificates •  Password Mgr •  E-SSO

Single Sign-On: Traditional Desktops

Password Mgr

Kerberos

Federation Certificates

Apps/OS supported

USABILITY

SSO to Applications: Mobile

SaaS •  Standards (Federation) •  Proprietary (WAM) •  Kerberos* •  Certificates* •  Password Mgr*

Native •  Kerberos* •  Certificates* •  E-SSO •  Wrap/SDK*

* Mileage varies

Challenges: Native App SSO

Apps Containerized. No Sharing

Some OS Vendors Support Shared Token (iOS 7 kerberos)

Password Managers do NOT Support Native (iOS) •  Also, security bypass

Single Sign-On: Mobile Native

Password Mgr

Kerberos

Federation Certificates

Native Apps/OS supported

USABILITY

Certificates WAM Kerberos

Approaches: Single Sign-On

Need Shared Token support by Mobile OS vendors • Today: iOS 7 kerberos token • Future: Oauth token?

Federation with Certificate Auth • Native Apps using Certificates •  IDP supporting Certificate Auth

EMM Vendors using Shared Token in Wrapper/SDK

Future: Single Sign-On: Mobile Native

Federation

Native Apps/OS supported

USABILITY

Certificates WAM Kerberos

Mobile Identity Takeaways

Authentication SSO Authorization

• Good UX Key

• Certificates and Biometrics Viable Options

• Federation Standards Prevent Bypass

• Username/PW Apps to Provide IP Restrictions

•  IDP to Use Device Context

• Mobile Vendors Enabling Shared Token Support

• Certificates

•  IDP Support for Certificate Auth

The technical realities…

There is no “one answer” to mobile SSO

•  Generally “I want SSO” means “I want transparent authentication”.

•  Shared tokens, while useful, don’t work extremely well for mobile today

•  Goals should be to make authentication & authorization easy while reducing UX complexity

But there are lots of implementation options

The rough architecture of EMM systems •  A client:

–  Serves to enroll users in the EMM policy server. –  Can serve as a central mechanism for driving policies & configs for apps

(MAM or app wrapping)

•  A server: –  A central system where administrators define policies and configurations

for devices, apps and data. Often houses App Storefront functions. –  Often ties to LDAP to direct policies against user or group objects –  Can tie to external systems for access control & identity including

certificate authorities, NAC, etc.

The rough architecture of EMM systems

•  A Gateway: –  Allows for transport of traffic to on-premise resources. Can be VPN

or purpose built –  Should tie to concepts around device and network trust – Ensure

that device is managed, that sessions aren’t hijacked, etc.

•  Mobile Device Management •  Mobile Application

Management •  Identity And Certs •  User Self-Service •  Rules & Reporting

MobileIron Client Enforces Configuration and Security policies on the device, apps and content at rest and in real time

Sentry (Gateway) Provides Access Control by Enforcing Security Policies on Apps and Content in-flight

The MobileIron Platform

Core (VSP) & Cloud: Mobile Policy Configuration Engine

MobileIron Confidential

EMM vendors build SSO …because a lot of customers said “We want to use our Windows architecture.” Result: Kerberos Constrained Delegation and Mobile

Kerberos

Content

Active Directory

Kerberos

App SSO using Kerberos: PC era

Content

Active Directory

Native Kerberos

App SSO : PC era

Kerberos Constrained Delegation

App single sign on (SSO) using KCD

Content

Active Directory

Kerberos

Requires app developer engagement (SDK / wrapper)

Requires trust relationship between gateway and AD infrastructure

No client certificate to app server auth supported

Constraints with KCD

Requires complex setup

Native app support (Safari, Chrome) and commercial app support may be limited

Apple takes on SSO iOS 7 introduces support for Kerberos

iOS 7: Native OS Kerberos SSO

Native iOS. Supports direct Kerberos requests from OS and native apps Device access to Key Distribution Center (KDC)

Use device VPN

Expose KDC in DMZ or

Content

Active Directory

Native Kerberos!

iOS 7 SSO Challenge

Sharepoint, OWA, Other Kerberos-

enabled apps

Kerberos Domain Controller (KDC)

Kerberos

First sign on: Kerberos Proxy

Subsequent

access: Per app VPN

iOS 7 SSO with Kerberos Proxy

Certificates weren’t supported until iOS 8 (watch this space)

Only supported on Apple devices

Constraints with Apple SSO

Native apps are supported including Safari

Token reuse is supported across applications

Standards begin to develop Introduction of AZA, now NAPPS

OAUTH enabled app

Identity Provider (IDP)

AZA / NAPPS approach R

Token Exchange

Deliver

Auth with token

Without OS integration, it remains a MAM-only driven model

Today requires app wrapping or SDK

Constraints with AZA / NAPPS

Standards work is still nascent

Another alternative… Use of certificates for “transparent authentication”

OAUTH enabled app

Identity Provider (IDP)

Certificate auth to SSO IDP

Auth with token

Receive user or machine certificate

Present certificate to IDP, receive

Store cert in app keychain

Constraints with cert-based auth to IDP Provides transparent authentication, but not “SSO”. Apps end up with new tokens if IDP does not know to reissue previous token from previous cert auth Works with iOS native apps, however requires developer work to negotiate cert auth & token request. Android requires app wrapping or SDK to receive certificate material and transport IDP request behind firewall Windows supports cert provisioning and app-access to cert store but transport to IDP needs development IDP must support OAUTH or SAML requests with certificates as the user identity

The takeaway

•  It is possible to meet end-user and IT needs for authentication today

•  IT should be aware of OS capabilities when planning both app and auth design

•  Certificates provide the easiest, most transparent method available.

•  NAPPS represents a strong development but needs more maturity and OS buy-in

cis14: providing security and identity for a mobile-first world

mobileiron confidential

mobileiron confidential

mobile sso

mobile access

native app sso apps

deployment esso

mobile leverage

kerberos password managers

Technology

cis14: is the cloud ready for enterprise identity and...

cis14: identity therapy: surviving the explosion of users,...

cis14: authentication: elderly people's ankles

cis14: double trouble—managing growth

cis14: are the enterprises ready for identity of everything?

cis14: physical and logical access control convergence

cis14: pingid

cis14: identity at scale: bridging gaps between physical and...

cis14: nstic - why the identity ecosystem steering group...

cis14: mobilize your workforce with secure identity services

cis14: implementing mitreid

cis14: how i came to share signals and learned to love my...

cis14: why federated access needs a federated identity

cis14: from card to mobile—evolving identity credentials

cis14: trusted tokens: an identity game changer

cis14: nstic - identity and access management collaborative...

cis14: lean in: enterprise cloud identity

cis14: the very latest in authorization standards

cis14: identity at scale: next gen federation architectures

cis14: identity souffle: creating a well-baked identity...