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

WAM

Federation SECURITY


E-SSO


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

WAM

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

WAM

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

WAM

Kerberos

Federation Certificates

Apps/OS supported

USABILITY

E-SSO


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

WAM

Kerberos

Federation Certificates

Native Apps/OS supported

USABILITY

E-SSO

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

Email

Apps

Content

Active Directory

Certs

Kerberos

App SSO using Kerberos: PC era


Email

Apps

Content

Active Directory

Certs

Native Kerberos

?

App SSO : PC era


Kerberos Constrained Delegation

(KCD)

App single sign on (SSO) using KCD

Email

Apps

Content

Active Directory

Certs

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

KCD


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

SSO


Email

Apps

Content

Active Directory

Certs

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

SSO

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

eque

st

toke

n

Token Exchange

Deliver

Token

Auth with token

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

Rec

eive

use

r or

mac

hine

cer

tific

ate

Receive user or machine certificate

Present certificate to IDP, receive

token

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

Technology

Transcript of CIS14: Providing Security and Identity for a Mobile-First World