Your SlideShare is downloading. ×
CIS13: Authorization Agent (AZA) Mobile Protocol
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

CIS13: Authorization Agent (AZA) Mobile Protocol

665
views

Published on

Observe the state of the AZA protocol interop. AZA leverages OpenID Connect to provide a standards-based approach for SSO to multiple native applications.

Observe the state of the AZA protocol interop. AZA leverages OpenID Connect to provide a standards-based approach for SSO to multiple native applications.

Published in: Technology, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
665
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Na#ve  Single  SignOn   Interop  Demonstra#on     Cloud  Iden#ty  Summit  2013   1
  • 2. 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      
  • 3. 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  
  • 4. 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  
  • 5. 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  
  • 6. AZA  Alterna#ve       6 Enterprise   SaaS   Device   Browser   Na#ve  SaaS   SaaS2   Na#ve  SaaS2   AS   AS   Client   Client  AZA  
  • 7. AZA  Alterna#ve       7 Enterprise   SaaS   Device   Browser   Na#ve  SaaS   SaaS2   Na#ve  SaaS2   AS   AS   Client   Client  AZA   AS  
  • 8. SaaS   AZA  Alterna#ve       8 Enterprise   Device   Browser   AZA   AS   Browser   Na#ve     SaaS  AZA   Na#ve     SaaS2   SaaS2  
  • 9. Alterna#ve       9 Enterprise   Device   Browser   Na#ve     SaaS   SaaS   AZA   Na#ve     SaaS2   SaaS2  AS  
  • 10. 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
  • 11. 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  
  • 12. 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
  • 13. Interop  Par#cipants   13
  • 14. Interop  Scenarios   14 AZA   AS   AZA   AZA   AS