Standards-based Secure Signon for Cloud and Native Mobile Agents

Transcription

1 Standards-based Secure Signon for Cloud and Native Mobile Agents P. Dingle July

2 Mobile Mobile devices offer potential of significant enhancements over static computing models in usability, convenience, and immediacy BUT Mobile devices present new challenges in user privacy & security of application data

3 Don t think Apps Change your Security Model? 3

4 Mobile Application Models Web Applications Web Server Native Applications Web Server Mobile Web Page HTML JSON/XML Mobile Device Mobile Device Web App Native App Browser 4

5 Tokens for Web Applications Identity Provider Service Provider Password Device 1 2 Token Mobile Web Page 3 HTML 1. User trades credentials for a token from IdP 2. Token delivered through the browser to SP 3. SP validates token, and delivers application HTML to browser Web App Browser 5

6 Tokens for Native Applications Service Provider 1. User trades credentials for a token 2. Token delivered through the browser to native application 1 Token Token 4 3. Native application presents token on API calls Device Password 2 3 JSON/XML 4. API endpoint returns application data as JSON/XML Browser Native App 6

7 Preferred Architecture An authentication & authorization framework for web and native applications built on federation standards Create consistent identity ceremonies across application channels Don t implement duplicate & incompatible security frameworks for the two models 7

8 Federation & Tokens Federation abstracts away from applications specifics of authentication & authorization Hidden by token issuance & validation Token standards define Token formats How clients obtain tokens How clients present tokens to applications 8

9 Default OAuth pattern for native applications Employee authentication/authorizes each application individually Authorization manifested as the issuance of an OAuth token to each native 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 9

10 Implications of default pattern Employee bears burden of authenticating/authorizing each native application separately Even if done infrequently, may be unacceptable Each SaaS must directly support OAuth (running an Authorization Server) Enterprise distanced from employee's use of native applications 10

11 Native App SSO Alternative An employee is able to collectively authorize each native application on device in one step Rather than each application individually obtaining OAuth tokens for itself the tokens are obtained on behalf of those native applications by a dedicated 'authorization agent' (AZA) Employee authorizes the AZA, which then proceeds to obtain for other applications the necessary access tokens Once handed the tokens, native applications use them as normal on API calls For user, enables an SSO experience for native applications 11

12 AZA Alternative Enterprise SaaS AS SaaS2 AS Device Browser AZA Native SaaS Client Native SaaS2 Client 12 12

13 AZA Alternative SaaS Enterprise AS AS SaaS2 AS Device Browser Native SaaS Native SaaS2 AZA Client Client 13 13

14 AZA Alternative Enterprise AS SaaS SaaS2 Device Browser AZA AZA Native SaaS Native SaaS

15 Alternative Enterprise AS SaaS SaaS2 Device Browser AZA Native SaaS Native SaaS

16 Implications 1. Native 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 native application 3. AZA must be able to hand over access tokens to native application 4. RS must be able to validate access tokens (potentially issued by a remote AS) 16 16

17 Standardization Multiple pieces (from different providers) implies need for standards A number of industry players working to profile/extend OpenID Connect for the AZA<- >AS interaction New WG being formed in OpenID Foundation Related but separate effort to standardize App<-> AZA messaging emerging 17

18 Interop Participants CIS

19 To Participate Information on joining the OpenID Foundation Working Group will be available at shortly Membership is not required to participate in working groups, but you must sign an IPR agreement Contact me on or for more information 19