Na#ve  Single  SignOn  Interop  Demonstra#on  

 Cloud  Iden#ty  Summit  2013  

1

Mo#va#on  

•  Enterprise  employees  use  mul#ple  applica#ons  (combo  of  web  &  na#ve)  in  their  jobs  

•  Applica#ons  both  hosted  on-­‐prem  &  SaaS  •  Current  reality  is  that  an  SSO  experience  limited  to  the  browser  apps  

•  But  na#ve  applica#ons  becoming  more  and  more  prevalent  

•  Poten#ally  significant  usability  burden  for  employees      

Default  OAuth  paNern  for  na#ve  applica#ons  

•  Employee  authen#ca#on/authorizes  each  applica#on  individually  

•  Authoriza#on  manifested  as  the  issuance  of  an  OAuth  token  to  each  na#ve  app  –  this  presented  on  subsequent  API  calls  to  corresponding  server  

•  Employee  interacts  with  each  OAuth  AS  (corresponding  to  each  API)  to  obtain  an  OAuth  token  

Implica#ons  of  default  paNern  

•  Employee  bears  burden  of  authen#ca#ng/authorizing  each  na#ve  applica#on  separately  

•  Even  if  done  infrequently,  may  be  unacceptable  

•  Each  SaaS  must  directly  support  OAuth  (running  an  Authoriza#on  Server)  

•  Enterprise  distanced  from  employee's  use  of  na#ve  applica#ons  

Na#ve  App  SSO  Alterna#ve  •  An  employee  is  able  to  collec#vely  authorize  each  na#ve  

applica#on  on  device  in  one  step  •  Rather  than  each  applica#on  individually  obtaining  OAuth  

tokens  for  itself  the  tokens  are  obtained  on  behalf  of  those  na#ve  applica#ons  by  a  dedicated  'authoriza#on  agent'  (AZA)  

•  Employee  authorizes  the  AZA,  which  then  proceeds  to  obtain  for  other  applica#ons  the  necessary  access  tokens  

•  Once  handed  the  tokens,  na#ve  applica#ons  use  them  as  normal  on  API  calls  

•  For  user,  enables  an  SSO  experience  for  na#ve  applica#ons  

AZA  Alterna#ve      

6

Enterprise  

SaaS  

Device  Browser   Na#ve  SaaS  

SaaS2  

Na#ve  SaaS2  

AS  

AS  

Client   Client  AZA  

AZA  Alterna#ve      

7

Enterprise  

SaaS  

Device  Browser   Na#ve  SaaS  

SaaS2  

Na#ve  SaaS2  

AS  

AS  

Client   Client  AZA  

AS  

SaaS  

AZA  Alterna#ve      

8

Enterprise  

Device  Browser  

AZA  

AS  

Browser   Na#ve    SaaS  AZA  

Na#ve    SaaS2  

SaaS2  

Alterna#ve      

9

Enterprise  

Device  Browser   Na#ve    

SaaS  

SaaS  

AZA  Na#ve    SaaS2  

SaaS2  AS  

Implica#ons  

1.  Na#ve  apps  must  be  able  to  request  access  tokens  of  a  local  AZA  

2.  AZA  must  be  able  to  request  access  tokens  on  behalf  of  another  na#ve  applica#on  

3.  AZA  must  be  able  to  hand  over  access  tokens  to  na#ve  applica#on  

4.  RS  must  be  able  to  validate  access  tokens  (poten#ally  issued  by  a  remote  AS)  

10

Standardiza#on  

•  Mul#ple  pieces  (from  different  providers)  implies  need  for  standards  

•  A  number  of  industry  players  working  to  profile/extend  OpenID  Connect  for  the  AZA<-­‐>AS  interac#on  – New  WG  being  formed  in  OpenID  Founda#on  

•  Related  but  separate  effort  to  standardize  App<-­‐>  AZA  messaging  emerging  

Interoperability  

•  We  are  demonstra#ng  interoperability  between  different  AZAs,  OAuth  ASs,  na#ve  applica#ons,  and  OAuth  RSs    

•  The  AZA<-­‐>AS  protocol  is  based  on  OAuth  (not  the  eventual  OIDC-­‐based  standard)  

•  MobileIron  &  Ping  also  implemented  a  back-­‐channel  authoriza#on  query  interface  

12

Interop  Par#cipants  

13

Interop  Scenarios  

14

AZA  

AS  

AZA   AZA  

AS