Date post: | 08-May-2015 |
Category: |
Technology |
Upload: | cloudidsummit |
View: | 701 times |
Download: | 0 times |
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