"Mobile" Client Security: Authentifizierung, Autorisierung, Personalisierung

Selbstverständlich müssen wir unsere mobilen Apps bzw. die dahinter liegenden Web-APIs absichern. Wenn wir in klassischen Systemen bisher mit "Username/Passwort" in der Anwendung gedacht haben, so müssen wir dies bei modernen Business- und mobilen Apps ändern. In dieser Session zeigen Dominick Baier und Christian Weyer architekturelle Wege und Implementierungen auf, um Authentifizierung und Autorisierung sicher über OAuth-2.0-basierte Ansätze abzuwickeln. Darauf aufbauend sehen Sie auch, wie mit der Idee von Tokens und Claims eine für Benutzer einfache Personalisierbarkeit Ihrer App realisiert werden kann – so schlagen Sie zwei Fliegen mit einer Klappe.

Transcript

1. Dominick Baier, Christian Weyer | thinktecture „Mobile“ Client Security: Authentifizierung, Autorisierung, Personalisierung think mobile!
2. Agenda • Mobile apps: native & web-based • Web-based client architectures • Authentication • Authorization • OAuth2 • Personalization • Summary 2
3. Mobile client apps • 'Mobile' is not just about devices – instead refers to a new way of working without being tied to a desktop in an office – users expect modern business applications to work on multiple devices, at multiple locations, online and offline • Mobile spans the whole stack – from native Windows 8 applications on laptop and tablets – to modern HTML5-based desktop applications – to classic Windows clients developed with WPF – to native applications developed for iPhone, iPad, Android and Windows Phone 3
4. Simplified overall architecture Human user Client applications Services / Data 4
5. Web-based single page applications (SPA) • Modern web-based applications are “the new smart client” – client assets (markup, styles & code) run in the browser (shell) • Single page approach offers similar features and behavior as a Windows application – page as shell, with views and routing • The client (aka the actions through the client) is untrusted • Native apps can use web view component to leverage security solutions 5
6. Secure communication for Web APIs • Web APIs (“REST”) typically use HTTP- intrinsic security mechanisms – combined with SSL for protection and server authentication – either standard HTTP credential types – …or (more or less) custom extensions to the HTTP authorization header Authorization: scheme credential GET /service 6
7. Special case Windows Integrated • Specific infrastructure requirements – Active Directory – Intranet, VPN • “It just works” – browser automatically sends credentials with requests – also works in Chrome, Safari, not just IE – similar to cookies  CSRF issues 7
8. CSRF – the problem Browser Tab/Process Tab/Process Login, get authentication cookie http://app.com http://app.com/delete/5 send authentication cookie 8
9. Implementing Windows authentication in Web API & AngularJS • Out-of-the-box for web-hosted in Web API v1 • Use of OWIN middleware in Web API v2 – for Web- and self-hosted • AngularJS’ AJAX APIs ($http, $resource) automatically pick up browser’s Integrated Windows Authentication features 9 <system.web> <authentication mode="Windows" /> …
10. Modern application security • Works across any platforms & systems – common denominator technologies • Factoring out authentication & authorization – separation of concerns – decoupling of technical details 10
11. Token-based authentication Client app Service / Web API Security Token Service 1 2 Token 11
12. Basic authentication with tokens • Basic authentication is widely used – easy to implement, server-side hooks into existing identity systems – do not store passwords! • HTTP‘s basic authentication can be extended to use a session token after initial username/password authentication – essentially doing authentication first, then allowing to present authorization information • Put JWT token onto Authorization header and present to Web API – token has expiration 12
13. Embedded token endpoint • Swap credential with (long-lived) token Authorization: Basic base64(username:password) GET /service/token <token> GET /service/resource Authorization: Bearer <token> 13
14. Implementing basic authentication with tokens in Web API & AngularJS • Use thinktecture IdentityModel • Submit login data (from user input), store & set token on header 14 var authenticationConfig = new AuthenticationConfiguration { EnableSessionToken = true, SessionToken = new SessionTokenConfiguration() { DefaultTokenLifetime = TimeSpan.FromHours(24), SigningKey = Convert.FromBase64String( "V5cgP0gguiOrFKUIPqUWRNmgpoH8IxXQ92M2T0E=") } }; authenticationConfig.AddBasicAuthentication((un, pw) => ...); config.MessageHandlers.Add(new AuthenticationHandler(authenticationConfig)); var auth = "Basic " + tt.Base64.encode(username + ":" + password); $http.defaults.headers.common["Authorization"] = auth; return $http.get(baseUrl + "api/token") .success(function (tokenData) { setToken(tokenData); authenticationSuccess(); });
15. What is OAuth2 ? 15
16. OAuth2 high level overview Resource Owner Client Resource Server 16
17. OAuth2: The players Resource Owner Resource Server Authorization Server Client issues access token Confidential/Public Trusted/Untrusted "owns" a resource uses trusts is registered with accesses 17
18. OAuth2 flows • Implicit Flow – Native / local clients 1. Request authorization & token 2. Access resource • Resource Owner Password Credential Flow – "Trusted clients" 1. Request token with resource owner credentials 2. Access resource 18
19. Implicit Flow (native / local clients) Resource Owner Client 19
20. Step 1a: Authorization request Resource Server Resource Owner Client GET /authorize? client_id=nativeapp& scope=resource& redirect_uri=http://localhost/cb& response_type=token& state=123 Authorization Server 20
21. Step 1b: Token response Resource Owner Client GET /cb# access_token=abc& expires_in=3600& state=123 Authorization Server Resource Server 21
22. Step 2: Resource access Resource Owner Client GET /resource Authorization: Bearer access_token Resource Server 22
23. OAuth2 application architecture Application Authorization Server Scopes: read, write, delete, search… client_id=client1, scope=search read access token access token { "iss": "myAuthzServer", "aud": "application", "exp": 192990121, "sub": "Bob", "client_id": "client1", "scope": [ "search", "read" ] } User 23
24. Implementing OAuth2 with ASP.NET Web API • Add JWT configuration via thinktecture IdentityModel • thinktecture Authorization Server as lightweight AS 24 var authenticationConfig = new AuthenticationConfiguration(); authenticationConfig.AddJsonWebToken( issuer: "AS", audience: "todos", signingKey: "1fTiS2clmPTUlNcpwYzd5i3eHFJ2DEsd8TcUsllmaKQ=", claimMappings: ClaimMappings.None); config.MessageHandlers.Add(new AuthenticationHandler(authenticationConfig));
25. Implementing OAuth2 with AngularJS • Use e.g. angularOauth and configure client settings • Trigger login/token retrieval – and set token on HTTP header 25 TokenProvider.extendConfig({ authorizationEndpoint: 'https://windows8vm/as/todos/oauth/authorize', clientId: "implicitclient", redirectUri: baseUrl + "oauth2callback.html", scopes: ["read"], verifyFunc: TokenNonVerifier }); $scope.login = function () { Token.getTokenByPopup() .then(function (params) { Token.set(params.access_token); $http.defaults.headers.common["Authorization"] = "Bearer " + params.access_token; }, function () { alert("Failed to get token."); }); };
26. Personalization • Need for “authorization” in the UI layer – which user can see or do what in the client application? – authorization always has to happen on the server, anyway • Technical concept of authorization morphs into user-oriented concept of personalization – features – capabilities – constraints 26
27. Personalization illustrated - I 27
28. Personalization illustrated - II 28
29. Implementing personalization in ASP.NET Web API • Model personalization data and populate from server- side repository 29 public class PersonalizationController : ApiController { public PersonalizationData GetPersonalizationData() { var persData = new PersonalizationData { Features = GetFeatures().Where(m => m.Users.Contains(User.Identity.Name)), UiClaims = new UiClaimsData { UserName = User.Identity.Name, Capabilities = GetCapabilities(User), Constraints = GetConstraints(User), NameValueClaims = GetNameValueClaims(User) } }; return persData; }
30. Implementing personalization in AngularJS • Get personalization data upon successful authentication • Implement AngularJS service to inject personalization data into controllers • Data-bind to e.g. capabilities on $scope – may use ng-if, ng-show etc. • Fully-fledged solution would include custom directives 30 $http({ method: "GET", url: ttTools.baseUrl + "api/personalization" }) .success(function (data) { tt.personalization.data = data; // populate routes from features… $rootScope.$broadcast(tt.personalization.constants.dataLoaded); }); app.factory("personalizationService", function () { return tt.personalization; });
31. Overall architecture Human user Client applications Services / Data 31
32. Resources • dominick.baier@thinktecture.com • christian.weyer@thinktecture.com • http://www.thinktecture.com • thinktecture’s GitHub Repositories – https://github.com/thinktecture • Christian Weyer’s GitHub Repositories – https://github.com/ChristianWeyer 32