Disclaimer Chances of me being misguided or even outright wrong with following statements are higher than average (my average, not Ashish's).

1

BYOD  is  (merely)  an  ownership  model,  

doesn’t  significantly  change  the  

fundamentals.  

2

no

Is device choice constrained?

enterprise Who owns device

yes

           BYOD  

employee

                       COPE  

           CYOD  

mass  resigna@ons  

of  IT  personnel  

IT'S NOT ABOUT THE DEVICE

It's  the  data  

MDM

MAM

MIM

Personal app

Business app

Enterprise control

Device

Premise  

•  Depending  on  context,  IT  will  impose  differen@ated  controls  – Use  camera  – Take  screenshot  – Wifi  – Email  account  to  use  

•  MDM,  MAM,  &  MIM  differ  in  the  granularity  of  the  context  they  account  for  

Contexts  •  Who  is  the  user?  

–  controls  based  on  employee  iden@ty  &  roles,  e.g.  IT  admin  vs  Sales  Director    

•  What  are  they  doing?  –  controls  based  on  what  applica@on  the  employee  is  using,  eg  viewing  

a  spreadsheet    •  Why  are  they  doing  it?  

–  controls  based  on  whether  the  employee  is  ac@ng  in  a  business  or  personal  persona,  eg  viewing  financial  projec@ons  vs  hockey  team  stats  

•  Where  are  they  doing  it?  –  controls  based  on  geoloca@on,  e.g.  in  office  vs  on  business  trip  –  controls  based  on  device,  e.g.  on  iPad  vs  Blackberry  

•  When  are  they  doing  it?  –  controls  based  on  @me  etc,  e.g.  office  hours  vs  weekend  or  last  @me  

user  signed  in  

MDM  

•  In  MDM,  the  context  is  the  device,  ie  policy  looks  like  –   "If  you  are  using  this  device,  then  you  cannot  use  public  wifi'  

•  Coarse  granularity  implies  that  the  enterprise  imposed  limita@ons  will  impact  non  business  use  of  device    

personal

Device usage

enterprise Device owner

enterprise

         None  of  your  business  

employee

                                         Your  business  

MAM  

•  In  MAM,  the  context  is  the  applica@on  being  used,  ie  policy  looks  like  –   "If  you  are  using  the  enterprise  Box  applica@on,  you  cannot  store  data  on  the  device'  

•  Medium  granularity  implies  that  there  will  need  to  be  mul@ple  versions  of  some  applica@ons,  those  that  the  user  wants  for  both  personas  

All apps

Those that are MAM-enabled

Those enabled to work with your preferred MAM

Those your employees want to use

Sweet spot

MIM  

•  In  MIM,  the  context  is  determined  by  the  informa@on  –  enterprise  data  carries  with  itself  the  policy,  ie  looks  like  –   "When  viewing/edi@ng  this  spreadsheet,  you  cannot  use  the  screenshot  func@on'  

•  A  single  applica@on  could  work  with  both  personal  &  enterprise  data  (if  MIM  enabled)  

 

Balancing  Act  

Security

Privacy Enablement

Standards

15

Pick any one

Privacy?  

the right to be let alone—the most comprehensive of rights and the

right most valued by

civilized menLouis Dembitz Brandeis

17

Separa@on  

18

Dual Persona in MDM

Dual Persona in MAM Dual Persona in MIM

Dual  persona  is  by  defini@on  an  iden1ty  concept.  

20

21

Extremely  over  simplified  mobile  security  model  

1. Ensure  that  user/app  can  access  only  appropriate  apps/data  

2. Protect  data  in  transit  3. Protect  data  on  device    4. When  necessary,  turn  off  access  

Mechanisms?  1.  Ensure  that  user/

app  can  access  only  appropriate  apps/data  

2.  Protect  data  in  transit  

3.  Protect  data  on  device    

4. When  necessary,  turn  off  access  

• Server-based access control as per groups/roles • Inter-app controls (eg Managed Open In etc)

• Stop issuing tokens • Revoke any extant tokens • Wipe data (or keys)

• Hardware level encryption • Application level encryption

• SSL or VPN etc • Secure SDKs, custom URL schemes

EMM  in  a  nutshell  

Business  Applica@on  

Business  Data  

EMM  server  endpoints  

Agent  

Con

figur

atio

n

Cre

dent

ials

Pol

icy

Dire

ctiv

es

Business  Data  

Generic  lifecycle  0.    Provision  accounts  1.  Install  app  (OPT?)  2.  Ini@al  user  authen@ca@on  3.  Bind  to  Server  4.  Download  policy  &  addi@onal  creden@als  5.  Use  creden@als  to  access  applica@ons  6.  Ongoing  management    

SCIM

SAML

OAuth

OIDC

Iden@ty  standards  &  EMM  

27

EMM  Apps  Apps  Apps  

Directory   SCIM  

SCIM  

SAML   OpenID  Connect  

OAuth  

SCIM  

•  Simple  Cloud  Iden@ty  Management  (or  System  Cross  Domain  Iden@ty  Management)  

•  RESTful  protocol  for  user  provisioning,  ie  create,  read,  updates,  deletes  

•  Emerged  from  large  SaaS  providers  &  ISVs  •  Under  IETF  standardiza@on  

28

Iden@ty  standards  &  EMM  

29

EMM  Apps  Apps  Apps  

Directory   SCIM  

SCIM  

SAML  

•  Security  Asser@on  Markup  Language  •  XMl-­‐based  framework  for  making  security  &  iden@ty  informa@on  portable  across  domains  

•  Architypical  applica@on  is  for  Web  SSO    •  Default  SSO  protocol  for  B2B,  SaaS  •  Google,  Salesforce,  WebEx,  etc    

30

OAuth  

•  Open  framework  for  authoriza@on  &  authen@ca@on  for  REST  APIs  

•  Emerged  from  consumer  web,  transi@oning  into  cloud  &  enterprise  

•  Notable  for  its  mobile  op@miza@ons  (rela@ve  to  precedents)  

•  IETF  standardized  •  Important  plagorm  for  other  standards,  UMA  etc  

31

Iden@ty  standards  &  EMM  

32

EMM  Apps  Apps  Apps  

Directory  

SAML  

OAuth  

Enterprise EMM provider

Browser EMM Agent

1

2 3

4

1)  EMM Agent loads EMM provider authn page

2)  EMM provider does SAML SSO to enterprise

3)  After SAML SSO, EMM provider issues OAuth access token to agent

4)  EMM Agent uses access token to pull policy etc down

5)  EMM provider returns policies etc 5

Leverage EMM provisioned creds

OpenID  Connect  

•  Profiles/extends  OAuth  for  iden@ty  use  cases  •  Under  standardiza@on  in  OIDF  •  Defines  new  

–  Id_token  –  standardized  token  format  for  iden@ty,  enables  Web  SSO  

– UserInfo  endpoint  –  standardized  API  for  airibute  sharing    

34

Iden@ty  standards  &  EMM  

35

EMM  Apps  Apps  Apps  

Directory  

OpenID  Connect  

Device  

Na@ve  SSO?  

Browser  

Resource  Server  

App  client  

Resource  Server  

App  client  EMM  Agent  

EMM  Server  

Authoriza@on  Server  

     

     

2��

                   Policy  &  Token

s  

1��

3��

                   API  

                   API  

4��

Wrapping  up  

•  Separa@on  (whatever  the  mechanism  &  the  UX)  between  work  &  personal  usages  promises  balance  of  security,  privacy,  enablement  etc  

•  Dual  persona  is  by  its  nature  an  iden@ty  concept  

•  Iden@ty  standards  have  a  role  to  play  in  enabling  dual  persona  

•  Lets  keep  conversa@on  going    

37