Native application Single SignOn
-
Upload
paul-madsen -
Category
Documents
-
view
794 -
download
4
Transcript of Native application Single SignOn
![Page 1: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/1.jpg)
Session ID:
Session Classification:
Paul MadsenPing Identity
IAM-F42B
Intermediate
Enabling SSO for native applications
![Page 2: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/2.jpg)
Mobile Modes
Source - 'How to Connect with Mobile Consumers' – Yahoo!
![Page 3: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/3.jpg)
![Page 4: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/4.jpg)
► Enterprise employees use multiple applications (combo of browser & native) in their jobs
► Current reality is that an Single Sign On (SSO) experience is limited to the browser apps
► As the number of native apps an employee uses each day increases, the burden of authenticating grows linearly
► Introducing a native 'authorization agent' onto device can mitigate this usability challenge – enabling a SSO experience for native applications
► Will present a standards-based model for the authorization agent interactions with server endpoints & native applications
Overview
![Page 5: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/5.jpg)
Multiple native apps calling independent providers – each with its own AS
Variations Provider Provider
AS AS APIAPI
Provider
AS API
Provider
AS APIAPI API
Multiple native apps calling single provider's multiple APIs– all sharing same AS Device
DeviceApp
AppApp
App App
App
![Page 6: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/6.jpg)
► Employee authentication/authorizes each native application individually
► Authorization manifested as the issuance of an OAuth token to each native app – this presented on subsequent API calls to corresponding server
► Initial token issuance requires the user of the application to be authenticated (either directly or vis SSO)
Default authentication pattern
![Page 7: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/7.jpg)
Default authentication pattern
7
App1
App2AS
AS RS
RS
Device Browser
Native App1
Native App2
Client
Client
![Page 8: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/8.jpg)
Default authentication pattern
8
App1
App2AS
AS RS
RS
Device
Native App1
Native App2
Client
ClientBrowser
![Page 9: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/9.jpg)
Default authentication pattern
9
App1
App2AS
AS RS
RS
Device
Native App1
Native App2
Client
ClientBrowser
![Page 10: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/10.jpg)
► Employee bears burden of authenticating (and potentially authorizing) each native application separately
► Even if done infrequently, may be unacceptable
► For workforce->SaaS, each SaaS must directly support OAuth (running an Authorization Server)
► Enterprise 'distanced' from employee's use of native applications – involved only at initial token issuance
Implications of default pattern
![Page 11: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/11.jpg)
► By introducing an AZA onto the device, an employee is able to collectively authenticate each native application on device in one step
► Rather than each application individually obtaining OAuth tokens for itself the tokens are obtained by a dedicated 'authorization agent' (AZA)
► Once handed the tokens from the AZA, native applications use them as normal on API calls
► Advantages► For user, enables an SSO experience for native
applications► For enterprise, provides a centralized control point for
application access
Native Authorization Agent
![Page 12: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/12.jpg)
AZA flow
12
App1
App2AS
AS RS
RS
Device Browser
Native App1
Native App2
Client
Client
![Page 13: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/13.jpg)
AZA flow
13
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
Client
AS AS
AS
![Page 14: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/14.jpg)
AZA flow
14
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
Client
AS
AZA
AS
AS
![Page 15: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/15.jpg)
AZA flow
15
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
Client
AS
AZA
AS
AS
![Page 16: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/16.jpg)
AZA flow
16
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
Client
AS
AZA
AS
AS
![Page 17: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/17.jpg)
AZA flow
17
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
Client
AS
AZA
AS
AS
![Page 18: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/18.jpg)
► Employee performs explicit authentication & authorization only for the AZA – results in tokens issued down to the AZA
► Other apps able to benefit from this AZA authentication for their own – AZA tokens used to obtain application tokens
► User can enjoy SSO across those native applications
Advantages
![Page 19: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/19.jpg)
► Multiple pieces (from potentially different providers) implies need for standards► AZA to Cloud AS► AZA to native SaaS ► SaaS to Cloud AS
► A number of industry players (including Ping Identity, Salesforce & VMWare) are working on a profile of OpenID Connect to meet the AZA use case
► For more information► http://goo.gl/bJJe2
Standardization
![Page 20: Native application Single SignOn](https://reader035.fdocuments.in/reader035/viewer/2022062320/558e28aa1a28abfd668b45d8/html5/thumbnails/20.jpg)
► Usability► Burden of authenticating/authorizing native applications
significantly reduced
► Enterprise control► More directly involved in token issuance► Simpler mechanism for revoking employee access to SaaS
applications
► Simplicity► Smaller SaaS can outsource OAuth functionality
Summary