Your SlideShare is downloading. ×
0
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
Single sign-on Across Mobile Applications from RSAConference
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

Single sign-on Across Mobile Applications from RSAConference

7,352

Published on

How to implement a standards-based architecture for mobile app Single Sign-On - Presentation from RSA Conference - …

How to implement a standards-based architecture for mobile app Single Sign-On - Presentation from RSA Conference -

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,352
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
107
Comments
0
Likes
5
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. Single sign-on across mobile applicationsFrancois LascellesChief architectLayer 7 Technologies
  • 2. Why SSO matters? Adoption UX Layer 7 Confidential 2
  • 3. Per-app SSO vs across-app SSO Per-App X-app X-app and X-domainWeb Cookies Cookies (domain • SAMLapps cookies) • Social login • Open ID ConnectMobile OAuth access tokensapps ? … and x-device … Layer 7 Confidential 3
  • 4. Mobile app isolation User-agent Domain A Webapp 1 Cookie domain A Webapp 2 webapps Cookie domain B Webapp 3 (can be different parties) APP A Access token 1 Domain A API 1 mobile apps APP B API 2 Access token 2 APP C API 3 Access token 3 Layer 7 Confidential 4
  • 5. Why extending SSO across apps? 1/21. Provider avoids managing user accounts IdP  Authenticate once trust  Consent to multiple providers Provider  By delegating authentication to a User Accounts Sessions trusted IdP, multiple providers User name User Shared secret State avoid managing user accounts Email and effectively provide SSO UX Layer 7 Confidential 5
  • 6. Why extending SSO across apps? 2/22. A group of coordinated apps domain - Example: a set of application targeting BYOD App A App B App C  Authenticate once  Consent to multiple applications IdP Layer 7 Confidential 6
  • 7. Enablers Client side  Provider side - Because each app works in isolation, - API infrastructure built-in with or there needs to be an app-to-app integrating with federation coordination - Even traditional web-based redirections require to switch between relying party app and browser app ID Federation API Security-as-a-service Infrastructure Apps Layer 7 Confidential 7
  • 8. Client side redirections and callback  On iOS, apps can switch between each other and pass information through the redirection URL - Each app registers its own URL scheme - Calling such a URL switches to the other app - App gets information back by providing a callback URL tailored to its own scheme step 1 openURL AppA://something?callback=AppB://somethingelse App A App BopenURL AppB://somethingelse?arg=that_thing_you_need step 2 Layer 7 Confidential 8
  • 9. Client side redirections and callback (continued)  Is that secure enough to pass a token? APPLE: “If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme. ” --link Layer 7 Confidential 9
  • 10. Redirection/callback limitations and risks What‟s at stake? Social - An app tricks you into letting it get an access token to call your social provider on your behalf - Malicious app discovers your email - Posts something embarrassing on your wall (maybe)  Enterprise - An app tricks you into letting it getting an access token meant for an enterprise app - Malicious app now has access to all the same data as the app it pretended to be Layer 7 Confidential 10
  • 11. Alternatives Note: on iOS 6, facebook login is „built-in‟ - Once an app is authorized, there are no redirections required and the exchange is presumably more secure But what if you don‟t trust the built-in social id broker? Or what if you want to implement your own SSO across a set of coordinated applications? - E.g. A set of enterprise apps targeting BYOD Layer 7 Confidential 11
  • 12. KeyChain Groups KC A KC B Shared Key Chain App A App B App A App B Applications signed by the same developer key can share a key chain Combining redirection/callbacks with keychain groups enables a more secure delegated authentication - You can still pass scope between applications using URL schemes - But the sharing of information between these apps can go through the secure KeyChain group Layer 7 Confidential 12
  • 13. Provider side enablers: OAuth  OAuth is the standard for an app to get an access token - The access token is what is used to consume APIs by the app  OAuth 2.0 defines different grant types (handshakes) for different situations1. OAuth handshake access token OAuth Authorization Server IdP2. API consumption OAuth Resource Server Backend API Layer 7 Confidential 13
  • 14. Provider-side enablers: OpenID Connect  NOT OpenID  Mimics social login pattern, but standardized  Leverage an OAuth handshake to delegate authentication OpenID Connect IdP1. OIDC handshake OAuth Authorization Server access token Id token2. Get user info /userinfo Now I know who user is Layer 7 Confidential 14
  • 15. Federating OAuth using SAML draft-ietf-oauth-saml2-bearer-xx - The SAML Bearer grant type lets an application get an access token in exchange for a SAML assertion - API Provider trusts ID Provider‟s signing certificate which is verified as part of the OAuth handshake ID Provider • SAML Web browser SSO • STS handshake Output: SAML Client API Provider application OAuth SAML Bearer Grant Output: access token Layer 7 Confidential 15
  • 16. Federating OAuth using JWT draft-ietf-oauth-jwt-bearer-xx - The JWT Bearer grant type lets an application get an access token in exchange for a JSON Web Token (JWT) - API Provider trusts ID Provider‟s JWS signature which is verified as part of the OAuth handshake (RSA or HMAC) - The JWT can be issued as part of a standard OpenID Connect handshake ID Provider OpenID Connect Handshake Output: id token (JWT) Client API Provider application OAuth JWT Bearer Grant Output: access token Layer 7 Confidential 16
  • 17. Federating OAuth across multiple APIs The same SAML or JWT can be trusted by multiple APIs ID Provider OpenID Connect Handshake Output: id token (JWT) trust Client API A application OAuth JWT Bearer Grant Output: access token API B Layer 7 Confidential 17
  • 18. Applicability to X-app mobile SSO On iOS, the JWT is stored in a shared keychain group This is only accessible to applications signed by a common developer key (enterprise key) App Group KeyChain Group PUT OpenID Connect Identity +id token (JWT) Delegate App API Provider • Access Control GET • IdP +access token App 2 OAuth JWT Bearer Grant +access token App 1 Layer 7 Confidential 18
  • 19. Role of various technology in mobile SSO?  WAM - Focuses on Web - Can be leveraged for management of permissions as part of mobile session handling  MDM - Focuses on device-side security - MAM can include user auth  API Management - API access control - Integrate with existing federation mechanism in place  VPN Connections - Does not provide application level security (no API access control) - Back door security hole in a mobile device - Better to enable strong auth from app to perimeter Layer 7 Confidential 19

×