Proces uwierzytelniania użytkownika

1. Wstęp teoretyczny
2. Tokeny – lekarstwo na wszystko?
3. Najpopularniejsze protokoły/standardy bezpieczeństwa
3.1. SAML 2.0
3.2. OAuth 2.0
3.3. OpenID Connect
3.3. Inne
4. Gotowe rozwiązania

Transcript

1. Proces uwierzytelniania użytkownika w aplikacjach internetowych Robert Witkowski
2. 2 Agenda 1. Wstęp teoretyczny 2. Tokeny – lekarstwo na wszystko? 3. Najpopularniejsze protokoły/standardy bezpieczeństwa 3.1. SAML 2.0 3.2. OAuth 2.0 3.3. OpenID Connect 3.3. Inne 4. Gotowe rozwiązania
3. 3 Agenda 1. Wstęp teoretyczny 2. Tokeny – lekarstwo na wszystko? 3. Najpopularniejsze protokoły/standardy bezpieczeństwa 3.1. SAML 2.0 3.2. OAuth 2.0 3.3. OpenID Connect 3.3. Inne 4. Gotowe rozwiązania
4. 4 Trzy podstawowe kroki procesu: 1. Identyfikacja (ang. identification) 2. Uwierzytelnianie (ang. authentication) 3. Autoryzacja (ang. authorization) 1. Wstęp teoretyczny
5. 5 Identyfikacja (identification) – deklaracja tożsamości przez podmiot. • W procesie logowania do aplikacji wpisujemy swój login (aplikacja to strona ufająca); • Podczas łączenia się z serwerem SSL, serwer przedstawia przeglądarce swój certyfikat (przeglądarka to strona ufająca); 1. Wstęp teoretyczny
6. 6 Uwierzytelnianie (authentication) – weryfikacja zadeklarowanej w kroku pierwszym tożsamości. • W procesie logowania do aplikacji korzystamy z jednej z technik uwierzytelniania (authentication mechanism), a następnie aplikacja ją weryfikuje; • Przeglądarka pobiera podpis cyfrowy złożony na certyfikacie przez urząd certyfikacji, a następnie weryfikuje go; 1. Wstęp teoretyczny
7. 7 Autoryzacja (authorisation) – potwierdzenie czy podmiot jest uprawiony do uzyskania dostępu do żądanego zasobu. • Aplikacja sprawdza uprawnienia zalogowanego użytkownika do konkretnego zasobu; • Przeglądarka sprawdza zapisane w certyfikacie serwera flagi keyUsage, weryfikując czy został on poświadczony przez uprawniony podmiot; 1. Wstęp teoretyczny
8. 8 • coś co wiesz (something you know) – hasło, klucz prywatny; • coś co masz (something you have) – token, karta kodów jednorazowych; • coś czym jesteś (something you are) – zabezpieczenia biometryczne, czyli rozpoznawanie twarzy, linii papilarnych, geometrii dłoni, brzmienia głosu, odczytywanie obrazu tęczówki oka; Stosowane metody 1. Wstęp teoretyczny
9. 9 Agenda 1. Wstęp teoretyczny 2. Tokeny – lekarstwo na wszystko? 3. Najpopularniejsze protokoły/standardy bezpieczeństwa 3.1. SAML 2.0 3.2. OAuth 2.0 3.3. OpenID Connect 3.3. Inne 4. Gotowe rozwiązania
10. 10 2. Tokeny – lekarstwo na wszystko?
11. 11 ICAgYWxnOiBIUzI1NiwNCiAgIHR5cDogSldUDQo= . ICAgaXNzOiByb2JlcnQsDQogICBleHA6IDE0MDAwMDMzNDMzLA 0KICAgYWRkaXRpb25hbF9wYXJhbTogZm9vDQogICBhZGRpdGlv bmFsX3BhcmFtMjogYmFyDQo= . SUNBZ1lXeG5PaUJJVXpJMU5pd05DaUFnSUhSNWNEb2dTbGRVRF FvPQ0KLiBJQ0FnYVhOek9pQnliMkpsY25Rc0RRb2dJQ0JsZUhB NklERTBNREF3TURNek5ETXpMQTBLSUNBZ1lXUmthWFJwYjI1aG JGOXdZWEpoYlRvZ1ptOXZEUW9nSUNCaFpHUnBkR2x2Ym1Gc1gz QmhjbUZ0TWpvZ1ltRnlEUW89DQo= 2. Tokeny – lekarstwo na wszystko?
12. 12 Standardy tokenów • JWT (JSON Web Token) • SAML 2.0 • SWT (Simple Web Token) • Kerberos 2. Tokeny – lekarstwo na wszystko?
13. 13 „JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.” 2. Tokeny – lekarstwo na wszystko?
14. 14 JWT - JSON Web Token 2. Tokeny – lekarstwo na wszystko?
15. 15 JWT - JSON Web Token Header { "alg": "HS256", "typ": "JWT" } Payload { "iss": "robert", "exp": 14000033433, "additional_param": "foo", "additional_param2": "bar" } 2. Tokeny – lekarstwo na wszystko?
16. 16 JWT - JSON Web Token Token eyJhbGciOiJIUzI1NiIsInR5cCI6Ik pXVCJ9 . eyJpc3MiOiJyb2JlcnQiLCJleHAiOj E0MDAwMDMzNDMzLCJhZGRpdGlvbmFs X3BhcmFtIjoiZm9vIiwiYWRkaXRpb2 5hbF9wYXJhbTIiOiJiYXIifQ . I993X6YbV6D0ynNzN1meKBI1q458mF LjyOjPIkJikkU Signature var headerPayloadEncoded = base64UrlEncode(header) + "." + base64UrlEncode(payload); HMACSHA256(headerPayloadEncoded, "secret"); https://jwt.io/ 2. Tokeny – lekarstwo na wszystko?
17. 17 2. Tokeny – lekarstwo na wszystko?
18. 18 2. Tokeny – lekarstwo na wszystko? SESSION
19. 19 2. Tokeny – lekarstwo na wszystko?
20. 20 2. Tokeny – lekarstwo na wszystko? OWASP Top 10 Most Critical Application Security Risk 1. Injection 2. Weak authentication and session management 3. XSS Dlaczego tokeny stały się popularne?
21. 21 Dlaczego tokeny stały się popularne? • Bezstanowość (NIE ZAWSZE!); • Przyjazne dla natywnych aplikacji mobilnych oraz IoT; • Oddzielenie uwierzytelniania od autoryzacji; • Oddelegowanie procesu uwierzytelnienia do Identity Provider’a; • Skalowalność; • Ochrona przed CSRF (ale czy na pewno?); • Działają nawet, jeśli użytkownik zablokuje ciasteczka; 2. Tokeny – lekarstwo na wszystko?
22. 22 Agenda 1. Wstęp teoretyczny 2. Tokeny – lekarstwo na wszystko? 3. Najpopularniejsze protokoły/standardy bezpieczeństwa 3.1. SAML 2.0 3.2. OAuth 2.0 3.3. OpenID Connect 3.3. Inne 4. Gotowe rozwiązania
23. 23 3.1. SAML 2.0 V2.0 - 2005
24. 24 SAML – podstawowe cechy Pośrednictwo w uwierzytelnianiu i automatyczne przekazywanie między systemami i aplikacjami informacji o uprawnieniach użytkowników. • Opiera się na tokenach XML’owych; • Bardzo obszerne, dużo informacji; • Powszechnie przyjęty, większość infrastruktur firmowych go używa; • Nie ogranicza się do przesyłania tylko po HTTP, można używać SOAPa, JMSa; • Duży próg wejścia; • Dosyć trudno się go stosuje w przypadku aplikacji mobilnych; • Bardzo dobrze nadaje się do tworzenia federacji, czyli współdzielenia różnych zasobów bez dostępu do bazy danych; 3.1. SAML 2.0
25. 25 3.1. SAML 2.0
26. 26 3.2. OAuth 2.0
27. 27 „OAuth 2.0 is the next evolution of the OAuth protocol…” https://oauth.net/2/ „The OAuth 2.0 Authorization Framework” https://tools.ietf.org/html/rfc6749 3.2. OAuth 2.0
28. 28 „OAuth 2.0 is not an authentication protocol.” https://oauth.net/articles/authentication/ 3.2. OAuth 2.0 / 61
29. 29 Głównym założeniem OAuth jest delegowanie autoryzacji. 3.2. OAuth 2.0
30. 30 Terminologia Aplikacja zwolenie-lekarskie (client) chce uzyskać dostęp (token) do naszej (resource owner) osi czasu (scope) na Facebooku (authorization server & resource server), żeby kontrolować czy w trakcie zwolnienia lekarskiego nie udostępniliśmy zdjęcia z wakacji  3.2. OAuth 2.0
31. 31 Scenariusze pozyskania tokena autoryzacyjnego • Authorization Code dla aplikacji server-side; • Implicit dla aplikacji mobilnych i aplikacji client- side; • Client Credentials do integracji systemów, aplikacja może robić coś sama (bez ingerencji użytkownika); • Resource Owner Credentials do logowania za pomocą loginu i hasła; 3.2. OAuth 2.0
32. 32 Authorization Code – początkowe zapytanie do serwera GET https://fb.com/v2.0/dialog/oauth? response_type=code& scope=read_timeline& client_id=zwolnienielekarskie& redirect_uri=https://zwolenienielekarskie.pl/callback 3.2. OAuth 2.0
33. 33 Authorization Code – serwer weryfikuje uprawnienia Czy jesteś aktualnie zalogowany na FB? TAK NIE LOG IN 3.2. OAuth 2.0
34. 34 Authorization Code – odpowiedź od serwera i ponowne zapytanie (docelowa prośba o token) Authorization Server Response GET /callback ?authorization_code=540gjt340ijg34t45h56hhh POST https://fb.com/v2.0/dialog/oauth/get_token client_id=zwolnienielekarskie& client_secret=zwolnienielekarskie_generated_secret& redirect_uri=https://zwolnienielekarskie.pl/callback& grant_type=authorization_code& code=540gjt340ijg34t45h56hhh 3.2. OAuth 2.0
35. 35 Authorization Code – odpowiedź z wygenerowanym tokenem HTTP 200 OK Content-type: application/json { "access_token": "6fgg1147fA781bc3fE9Rr312", "token_type": "Bearer" } Przykładowe zapytanie do API GET https://fb.com/pracownik_na_zwolnieniu/timeline Authorization: Bearer 6fgg1147fA781bc3fE9Rr312 3.2. OAuth 2.0
36. 36 OAuth 2.0 – kto używa? * *Tylko Client Credentials 3.2. OAuth 2.0
37. 37 OAuth 2.0 – alternatywa? 3.2. OAuth 2.0 Oz is a web authorization protocol based on industry best practices. Oz combines the Hawk authentication protocol with the Iron encryption protocol. iron is a cryptographic utility for sealing a JSON object using symmetric key encryption with message integrity verification. Hawk is an HTTP authentication scheme using a message authentication code (MAC) algorithm to provide partial HTTP request cryptographic verification.
38. 39 OpenID Connect Uwierzytelnianie + autoryzacja? OpenID Connect – rozwiązanie oparte o OAuth, ale rozszerzone o możliwość zarządzania tożsamością posiadacza tokena oraz zarządzanie sesją. Dzięki temu może być wykorzystywane w rozwiązaniach SSO. „Architektura rozproszonego uwierzytelnienia i dystrybucji tożsamości użytkowników w usługach webowych.” Identyfikacja i uwierzytelnianie Protokół bazowy 3.3. OpenID Connect
39. 40 Scenariusze pozyskania tokena autoryzacyjnego • Authorization Code dla aplikacji server-side; • Implicit dla natywnych aplikacji mobilnych i aplikacji client-side; • Hybrid dla specyficznych przypadków, gdy back- end i front-end chcą otrzymywać token niezależnie; 3.2. OpenID Connect
40. 41 ID Token Payload / Claims { "sub" : "alice", "iss" : "https://openid.c2id.com", "aud" : "client-12345", "nonce" : "n-0S6_WzA2Mj", "auth_time" : 1311280969, "acr" : "c2id.loa.hisec", "iat" : 1311280970, "exp" : 1311281970 } 3.2. OpenID Connect
41. 42 Authorization Code GET https://fb.com/login? response_type=code& scope=openid& client_id=zwolnienielekarskie& state=5gtghtrh432& redirect_uri=https://zwolenienielekarskie. pl/callback 3.2. OpenID Connect
42. 43 Authorization Code – serwer weryfikuje uprawnienia Czy jesteś aktualnie zalogowany na FB? TAK NIE LOG IN 3.2. OpenID Connect
43. 44 Authorization Code – odpowiedź od serwera i ponowne zapytanie (docelowa prośba o token) Authorization Server Response GET /callback ?code=540gjt340ijg34t45h56hhh& state=436436fhwegd POST https://fb.com/token Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW redirect_uri=https://zwolnienielekarskie.pl/callback& grant_type=authorization_code& code=540gjt340ijg34t45h56hhh 3.2. OAuth 2.0
44. 45 Authorization Code – odpowiedź z wygenerowanym tokenem HTTP 200 OK Content-type: application/json { "id_token": "6fgg1147fA781bc3fE9Rr.asdasdsad3eqr.wadas", "access_token": "6fgg1147fA781bc3fE9Rr312", "token_type": "Bearer", "expires_in": 3600 } 3.2. OAuth 2.0
45. 46 StackExchange Microsoft Account OpenID Connect – przykładowe implementacje 3.3. OpenID Connect
46. 47 Kerberos • Zaprojektowany, by uwierzytelniać maszyny bez przesyłania haseł po sieci; • Oparty o bilety (ang. tickets), wykorzystujący zaawansowaną kryptografię; • Nie jest proste na pierwszy rzut oka; • Standardowy mechanizm uwierzytelniania w Windowsach od wersji 2000; • Wbudowany w Microsoft Active Directory; 3.4. Inne
47. 48 Kerberos – Desktop SSO • Aplikacja internetowa korzysta z biletu Kerberos’a, który został nadany użytkownikowi przy logowaniu do systemu operacyjnego; • Przeglądarka potrafi pobrać bilet i przesłać go w headerze HTTP; • Dostępne gotowe moduły Apache; • Natywne wsparcie w JDK od wersji 7; 3.4. Inne
48. 51 Agenda 1. Wstęp teoretyczny 2. Tokeny – lekarstwo na wszystko? 3. Najpopularniejsze protokoły/standardy bezpieczeństwa 3.1. SAML 2.0 3.2. OAuth 2.0 3.3. OpenID Connect 3.3. Inne 4. Gotowe rozwiązania
49. 52 Gotowe rozwiązania – po co ich używać? Serwer autoryzacyjny potrafi komunikować się wykorzystując potrafi oddelegować uwierzytelnienie do 4. Gotowe rozwiązania
50. 53 4. Gotowe rozwiązania
51. 54 4. Gotowe rozwiązania
53. 56 U2F – Universal 2nd Factor
54. 57 Klucz, podczas logowania do serwisu, dzięki API przeglądarki: 1. weryfikuje URL serwisu, 2. a po poprawnej weryfikacji, wykonuje “w sobie” na tzw. “bezpiecznym elemencie”, uwierzytelnienie dzięki kryptografii asymetrycznej. U2F – Universal 2nd Factor
56. 59 Podsumowanie • Tokeny nie są złotym środkiem, zawsze trzeba odpowiednio przemyśleć sposób uwierzytelniania i autoryzacji; • SAML jest dojrzałym standardem korporacyjnym, dzięki któremu można zaimplementować uwierzytelnianie oraz autoryzację; • OAuth 2.0 nie służy do uwierzytelniania tylko do delegowania autoryzacji, jego głównym założeniem jest oddzielenie uwierzytelniania od autoryzacji; • Sposób pozyskania tokena Resource Owner Credentials nie powinien być wykorzystywany NIGDY; • OpenID Connect jest rozszerzeniem OAuth, który przystosowany jest do tworzenia rozwiązań SSO i zarządzania sesją; • W zakresie bezpieczeństwa warto bazować na sprawdzonych, gotowych rozwiązaniach, tzn. zamiast pisać swój serwer autoryzacyjny, warto przetestować rozwiązania open-source typu Keycloak/Gluu;