Realizacja aplikacji internetowych

Prezentacja na temat: "Realizacja aplikacji internetowych"— Zapis prezentacji:

1 Realizacja aplikacji internetowych
Security

2 Scenariusze wg. MS Internet - klient anonimowy

3 Scenariusze wg. MS Intranet - klient bez zabezpieczeń

4 Scenariusze wg. MS Zabezpieczenie na poziomie transportu – klient anonimowy

5 Scenariusze wg. MS Zabezpieczenie na poziomie transportu – podstawowa autoryzacja

6 Scenariusze wg. MS Zabezpieczenie na poziomie transportu –autoryzacja Windows

7 Scenariusze wg. MS Zabezpieczenie na poziomie transportu –autoryzacja certyfikatem

8 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –klient anonimowy

9 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –znany klient

10 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –klient identyfikowany certyfikatem

11 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –klient Windows

12 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –klient Windows bez negocjacji tożsam.

13 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –wzajemne certyfikaty

14 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –zaufany podsystem

15 Scenariusze wg. MS Zabezpieczenie na poziomie komunikatu –zaufany podsystem

16 Autoryzacja ASP.NET Membership API Integracja z domeną

17 OAuth OAuth – 2007 – umozliwia wykorzystanie trzeciej strony jako dostarczyciela tożsamości web based access delegation bazował silnie na Flickr’s API Auth and Google’s AuthSub Flows - scenariusze OAuth2 – 2010 Umożliwia użycie przez aplikacje bez kryptografii – aplikacje mobilne Mniej skomplikowane sygnatury+noew scenariusze Acces tokeny żyją krótko (1.0 miesic, rok?) Jasna separacja ról obsługi żądań vs. obsługa autoryzacji

18 OAuth 2 Role Resource Owner: użytkownik
Resource Server: server hostujący zasób Client: apkikacja z której korzysta użytkownik np. aplikacja www, kod Javascript lub aplikacja mobilna Authorization Server: serwer który wystawia access token dla klienta. Serer może jednocześnie hostować zasób

19 OAuth 2 Tokeny Access Token: pozwala na dostęp do zasobu/aplikacji itd. Ma ograniczony czas życia. Jestdołączany do requestów. Refresh Token: token jest używany razem z AT do przedłużenia ważności AT. Czasem nie jest udostępniany przez serwaer autoryzacji. Claim = twierdzenie np. odnosnie tozsaamosci, wieku, roli przynależności

20 OAuth 2

21 OAuth 2

22 OAuth 2

23 OAuth 2

24 Problem Oauth 2 – to raczej framework do budowy protokołów adresujący różne scenariusze niż gotowe rozwiązanie Efekt: różne biblioteki klienckie dla różnych providerów tożsamości

25 OpenID Connect Protokół bazujący na Oauth 2.0
Domyślnie używa Rest/Json Wystartował luty 2014 Od 2015 wspierany przez Google, Microsoft, Ping Identity, ForgeRock, Nomura Research Institute, and PayPal OpenID Connect

26 Ochrona uSerwisów

27 Ochrona uSerwisów

28 Ochrona uSerwisów

29 Ochrona uSerwisów JWT – JSON Web Token SAML -> claims based
Służy do propagacji tożsamości między zainteresowanymi stronami. Propaguje uprawnienia miedzy stronami W praktyce JWT nie istnieje samodzielnie tylko w postaci JWS - JSON Web Signature (podpisany) JWE - JSON Web Encryption (zaszyfrowany)

30 Ochrona uSerwisów Źródło

31 Ochrona uSerwisów