Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

EduID Mobile App - Use-Cases, Concepts and Implementation

636 views

Published on

This presentation describes the token-agent implementation for openID Connect for authenticating native mobile apps provided by third parties. It presents a standards-based working solution for integrating loosely coupled native apps into a trust federation using. This allows for deeper integrated authentication services on Android and iOS without violating app-store policies.

This presentation has been part of the EduID Mobile App workshop at SWITCH on 25 Apr. 2017.

Thanks to Christoph Graf (SWITCH), Riccardo Mazza (USI), Michael Hausherr (FHNW), Goran Josic (USI), and Yann Cuttaz (USI).

Published in: Technology
  • Be the first to comment

  • Be the first to like this

EduID Mobile App - Use-Cases, Concepts and Implementation

  1. 1. FHO Fachhochschule Ostschweiz EduID Mobile App Use-cases, Concepts, Implementation
  2. 2. @phish108 @htwblc Part I Use Cases and Concepts
  3. 3. The “Cloud” from a Service Perspective Clients @phish108 @htwblc
  4. 4. The “Cloud” from a Device Perspective Roaming Profiles @phish108 @htwblc
  5. 5. The “Cloud” from a User Perspective Smart Environments @phish108 @htwblc
  6. 6. Shifting from Feature Services to Smart Environments Glahn (2013). What we mean when we talk about mobile services. SIG Mobile Whitepaper @phish108 @htwblc
  7. 7. Personalization requires Authorization Seite 6
  8. 8. Authorization is about Trust Organization Trusted User & App Store Trusted Mobile DeviceService Federation Untrusted Personal Data Internet @phish108 @htwblc
  9. 9. 1. OIDC for Responsive Web-Apps 2. AppAuth for tightly integrated native mobile apps 3. Token Agent Authorization for loosely coupled native apps @phish108 @htwblc 3 Approaches
  10. 10. Approach 1: Responsive Web-Apps (OpenID Connect / OAuth2, SAML) @phish108 @htwblc
  11. 11. Open ID Connect: 3 Flows to Authorizations @phish108 @htwblc 1. Implicit flow • Get an authorization from an IDP for accessing a service with limited session details 2. Code flow • Receive an authorization code for fetching confidential session details from the IDP 3. Hybrid flow • Get an authorization from an IDP for accessing a service with confidential session details in one step
  12. 12. OpenID Connect (OIDC) 26.04.2017Corporate IT, FHNW 11 «A Simple Identity layer on top of OAuth 2.0» From the website (http://openid.net): − OIDC is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of «making simple things simple and complicated things possible». It’s uniquely easy for developers to integrate, compared to any preceding Identity protocol. − OIDC allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.
  13. 13. SAML vs OIDC vs OAuth 26.04.2017Corporate IT, FHNW 12 Simply said: − SAML: single sign-on for enterprise users − OAuth: API authorization between applications − OIDC: single sign-on for consumers + API access Token format: − SAML: XML − OIDC: JWT (JSON web token) The whole story: «Unifying Authentication & Delegated API Access for Mobile, Web and the Desktop with OpenID Connect and OAuth2 by Dominick Baier» https://vimeo.com/113604459
  14. 14. GET /authorize ?client_id=app1 &scope=openid profile &redirect_uri=https://app.com/cb &response_type=id_token token &state=af0ifjsldkj &nonce=n-0S6_WzA2Mj Implicit Flow 26.04.2017Corporate IT, FHNW 13 − One of multiple flows (processes) defined in the specification − Specifically designed for «untrusted clients» such as JavaScript apps − Key steps: − Client sends the request to the Authorization Server. − Authorization Server authenticates the End-User, obtains consent, sends him/her back to the Client with an ID Token and, if requested, an Access (Bearer) Token. − Client validates the tokens and retrieves the End-User's Subject Identifier. − Client uses the Access Token for calls to Backend Web Services
  15. 15. @phish108 @htwblc Approach 2: Integrated Service Apps or Service-bound Apps (AppAuth)
  16. 16. © 2017 SWITCH | 15 Startseite Untertitel Unternehmenspräsentation Christoph Graf, Rolf Brugger swisseduid@switch.ch SIG Mobile, 25.4.2017 @SWITCH Use case of a “Service-bound Mobile App” SWITCHdrive App
  17. 17. SWITCHdrive Sync & share on Swiss servers Keep your data on your devices synchronized and share them with your contacts – on secure safe servers Your benefits • Data in Switzerland • Fast network connection to SWITCH • Simple user activation Customers • Universities • Hospitals • Other institutions Services • SWITCHdrive- Serverfarm, based on ownCloud • High dissemination in academic Switzerland (>80% of universities)
  18. 18. SWITCHdrive App – The official mobile client of the SWITCHdrive service • SWITCH-branded, based on owncloud app • Preconfigured with fixed endpoints for SWITCHdrive • Feature set in line with SWITCHdrive capabilities • Support limited to this app Usage scenario description
  19. 19. • Controlling the user experience end-to-end • Service branding opportunity (CI/CD) • Needs to maintain an app (development/adaptation/preconfiguration/testing, mobile martketplaces, etc.) • One single app to document and support • No re-use opportunity of potentially compatible app Service operator perspective
  20. 20. • Opportunity to develop, adapt, brand, preconfigure or support app exclusively for specific services as a contractor to service operator • (Probably) no opportunity to offer alternatives to users bypassing service operator • Uses standard authentication mechanisms (AppAuth, OAuth2, OIDC): availability of libraries, development and testing tools, tutorials. App developer perspective
  21. 21. www.switch.ch/30years SWITCH – an integral part of the Swiss academic community since 1987.
  22. 22. @phish108 @htwblc Approach 3: EduID Mobile App (Token-agent assertions)
  23. 23. • Multi-LMS learning app • API dependent, not service dependent • No separate backend service • Entering and managing authorizations cumbersome • Major UX barrier • Specialized solution for some didactics @phish108 @htwblc The Story of Mobler
  24. 24. @phish108 @htwblc How relevant are these cases for your institution?
  25. 25. @phish108 @htwblc Part II EduID Mobile App Architecture
  26. 26. @phish108 @htwblc EduID Mobile App Reference Architecture 1 234 5
  27. 27. • Focus on business logic • Completely external SSO • Federation independence • Loose bounds with specific services and instances • Independence of specific authorization mechanics • Multi factor authorization • Service-level authorization • Customers binding @phish108 @htwblc Benefits for Developers
  28. 28. • Continuous but flexible authorization and access control • Apps will not see forbidden service endpoints • Apps will not know authorization endpoints • Easier adoption of apps • No immediate need for app customizations @phish108 @htwblc Benefits for Organizations
  29. 29. • One stop authorization and identity management • No need to enter URLs in apps. • No need to enter passwords all the time • Transparent and explicit authorization of services @phish108 @htwblc Benefits for Actors
  30. 30. Requirements • Minimum Changes compared to OpenID Connect implementations • No Interference with existing OpenID Connect and AppAuth • Only standardized concepts (RFC-level) @phish108 @htwblc Implementation Requirements for Service Providers
  31. 31. Solution • Variation of OAuth2/OpenID Connect Code Flow • Trust-agent initiates the code request phase, directly • No separate authorization step • All request parameters are forwarded to the OAuth2 endpoints • Service extends code request with the required OAuth2 scope @phish108 @htwblc Implementation Requirements for Service Providers
  32. 32. @phish108 @htwblc PHP-CodefromtheMoodleImplementation if (array_key_exists("id", $_GET)) { // Step 1: Code-flow, Hybrid-Flow // normal use when the user comes via the login page // triggers the authorization request $callback->handleAuthorization(); } elseif (array_key_exists("state", $_GET)) { // Step 2: Code-flow, Hybrid-Flow // response from the authorization endpoint $callback->authorizeUser(); } elseif (array_key_exists("assertion", $_GET)) { // EduID Extension: rfc7521 forwarding $callback->authorizeAssertion(); } else { // bad request or OAuth2 error http_response_code(403); exit; }
  33. 33. public function authorizeAssertion() { // rfc7521 forwarding: extend the incoming assertion parameters $param = array_merge($_GET, ["scope"=> "openid profile email"]); // Fetch the access-token and user–information // - this is the same call as in step 2 of the Code Flow $res = $this->callTokenEndpoint($param); if (!$this->handleToken($res)) { http_response_code(403); } } @phish108 @htwblc PHP-CodefromtheMoodleImplementation
  34. 34. Reduction of Business Logic • Authorization request via mobile-OS instead of self-authorization • Self-identification • Service or service-capability demands • Single or multi-endpoint handling • Endpoint and token management (as usual) @phish108 @htwblc Implementation Requirements for App Developers
  35. 35. App Authorization for Service
  36. 36. Further reading http://htw.ac/eduid-mobile @htwblc http://htw.ac/blc-blog FHO Fachhochschule Ostschweiz

×