Aplikacja od SaaS do IdaaS December 12,2013 Aplikacja od SaaS do IdaaS Tomek Onyszko, tomasz.onyszko@predica.pl, @tonyszko Warszawa, 07.04..2014

Tomek Onyszko mvp – enterprise security (od 2005 – usługi katalogowe) December 12,2013 Tomek Onyszko mvp – enterprise security (od 2005 – usługi katalogowe) identity architect @ blog – http://onyszko.com twitter: @tonyszko speaker – TechEd, MTS, The Experts Conference, community

December 12,2013

December 12,2013 O czym będziemy mówić … … świat się staje połączony. W połączonym świecie aplikacje potrzebują tożsamości użytkownika, tożsamość użytkownika potrzebuje swojej manifestacji w urządzeniach, aplikacjach. Obecny model się nie sprawdza. Przynajmniej nie w skali jaka oferuje w tej chwili internet I w rożnorodności jaką oferuja. Użytkownik używa web, native App. Web I Native app używają API. Użytkownik oczekuje takiego samego user experience na wszystkich urządzeniach. Łatwo I przyjemnie. Jak to zapewnić i jakie narzędzia mamy na tą chwilę. O tym własnie bedzie – z punktu widzenia architekta, obecnej wizji świata I dostępnych standardów

December 12,2013 Jeżeli chodzi o aplikację to po co aplikacji jest tożsamość użytkownika? Określenie tożsamości użytkownika jest w zasadzie jednym z pierwszych zadań wykonywanych przez aplikację. Dlaczego? Dlatego, że aplikacja potrzebuje tożsamościu użytkownika, aby określić jego kontekst w aplikacji. Kontekst, pozwala aplikacji określić co dany użytkownik może wykonać w aplikacji, zaprezentować mu odpowiedni zestaw danych I jego opcje / preferencje. W przeszłości użytkownik przeważnie miał jeden kontekt w aplikacji, związane to było z tym, jak tworzone I używane były aplikacje. Teraz w ramach jednej aplikacji nawet użytkownik może miec różne konteksty – najprostrzy przykład to Facebook. W ramach Facebook użytkownik może mieć kontekst prywatny jak I jeden lub wiele nawet kontekstów związanych z prowadzoną działalności. Case CNAQ - o ile jest czas.

tożsamość i kontekst Architekt Prelegent Prywatnie - ojciec Atrybuty December 12,2013 tożsamość i kontekst Architekt Prelegent Atrybuty Imię: Tomasz Nazwisko: Onyszko Stanowisko: Architekt Firma: Predica Zanim przejdziemy dalej to chwila o samej tożamości I kontekstach. Czym w zasadzie jest tożsamość w swiecie cyfrowym. Tożsamość, nawet tak jak to definiuje odpowiednie RFC to zestaw atrybutów nas opisujących. Najlpeiej gdy te atrybuty pochodzą z zaufanego źródła I są w jakiś sposób potwierdzone. W większości obecnych aplikacji tak naprawdę źródłem atrybutów jest sam użytkowników wypełniający kolejny formularz. Dygresja – nie wiem jak wy ale ja mam tego dosyć. Zdarza mi sie nie rejestrować w aplikacji dlatego że musze wypełnić formularz. To prawda – coraz częściej te formularze korzystają z Facebook albo Google. Tak, ale w większości tylko po to, żeby stworzyć swój własny profil -> Spotify. I dodatkowo – to rozwiązania zamykające nas w kolejnych silosach. A powinniśmy móc wyrazić swoją tożsamość w różnych kontektach. Na przykład ja moge określić nawet kilka kontekstów dla siebie. Zawdowow -> architect Czasami -> prelegent Prywtnie -> ojciec W ramach każdej z niej mogę chcieć użyć innych metod I udostępnić inne informacje o sobie. Ale nadal ja jako tożsamośc je spinam, Prywatnie - ojciec

aplikacje i tożsamość Ustalić kontekst Autoryzacja Uwierzytelnienie December 12,2013 aplikacje i tożsamość Ustalić kontekst Autoryzacja Jak tożsamość jest obsługiwana w większości przypadków dotychczas. Jak powiedziałem aplikacja potrzebuje tożasmości użytkownika żeby ustalić jego kontekst. Kontekst jest potrzebny po to, aby autoryzować działania użytkownika. Dodatkowo też żeby pobrać jego profil. Jak aplikacja uzyskuje kontekst użytkownika -> poprzez jego uwierzytelnienie. A jak większośc aplikacji wykonuje uwierzytelnienie w tej chwili … poprzez login I hasło Dygresja – login I hasło. Uzywamy ich tylko dlatego że użytkownicy są do nich przyzwyczajeni I a I my mamy tak ustawiony mindset. Co tak naprawde dowodzi logi I hasło. Czy potwierdza nasz kontekst? Czy potwierdza że to my? Nie – potwierdza tylko że znamy login I hasło I że kiedyś już tu my lub ktoś kto założył ten login I hasło już tuta był. Po uwierzytelnieniu aplikacja potrzebuje pobrać nasze dane autoryzacyjne I profil. Tutaj króluja bazy danych SQL i katalogi takie jak LDAP. Często te same, które służą do uwierzytelnienia. W przypadku obu operacji -> uwierzytelnienia I autoryzacji, można spotkać w aliakcjach zupełnie egoztyczne rozwiazania. Chociaż mamy standardy często ktoś dochodzi do wniosku że zrobi to lepiej . Pytanie – kto powiela ten schemat działania w tej chwili w swoich aplikacjach? Uwierzytelnienie

problemy obecnego podejścia December 12,2013 problemy obecnego podejścia wymaga od aplikacji utrzymywania informacji o tożsamości zarządzanie poświadczeniami ryzyko wycieku danych i konieczność nim zarządzania Problemy związane z tym podejsciem: Bierzemy na siebie odpowiedzialność za utrzymanie tych danych. W szczególności za utrzymanie poświadczen Musimy implementowac dodatkowe funkcje w aplikacji do ich zarządzania Musimy implementować obsługę profile \ danych autoryzacyjnych Tworzymy też dla użytkowników kolejne dane do utrzymania I co najważniejsze, ryzykujemy ich wyciek Case LinkedIn

świat 20xx … raczej szybko December 12,2013 świat 20xx … raczej szybko nie kontrolujemy infrastruktury – IaaS nie kontrolujemy aplikacji – SaaS nie kontrolujemy urządzeń – BYOD urządzenie … to wszystko dookoła – IoT (IoEE) Dodatkow – świat się zmienia: We don’t control infrastructure anymore We don’t control applications anymore We don’t control devices And device concept has changed – it is not a computer as we define it anynmore

API stupid … API economy December 12,2013 API stupid … API economy API bedą (są?) głównym sposobem wymiany danych ilość otwartych API gwałtownie rośnie przewidywane 250k API w 2016 API potrzebują tożamości Głowny powód dla którego musimy zmienić podejście to API Economy. API stają się głównym sposobem wymiany danych pomiędzy systemami \ aplikacjami. Liczba API gwałtownie rośnie, ruch powodowany przez API gwałtownie rośnie API potrzebują infomracji o tożsamości – a raczej API potrzebują informacji o dostepie, które przekazują im aplikacje, które powinny potwierdzić tożsamość użytkownika.

December 12,2013 W tym świecie mamy jedną rzecz która I my I użytkownik możemy kontrolować – tożsamości. One thing you will be in control – sort of – will be user identity and how you apply it over these concepts (access to infrastructure, applications, devices) http://www.flickr.com/photos/buhsnarf/1196769516/

Identity is a new king! Web \ Mobile Enteprise APIs December 12,2013 Tożsamość użytkownikow powoli stanie się jedna stała naszego “świata”. To będzie coś co będzie łączyć różne światy, aplikacij enterprise, aplikacji web, API. Uzytkownik będize przez swoje interakcje z tymi rozwiazaniami przenosil swoja tożsamości I wykonywał jej projekcji na nasze rozwiazania Użytkownik potrzebuje prostego sposobu jak to robić, łatwo I bez koniecznosci pamiętania dodatkowych poswiadczeń. Dodatkowo – użytkownik potrzebuje sposobu wygenerownaia odpowiedniego kontekstu dla aplikacji w prosty sposób. Nie chcemy sie dwa razy rejestrowac w aplikacji z której korzystamy zawdowo jak I prywatnie. A nawet jezeli rejestracja w jakis sposob jest potrzebna to chcemy tak naprawde wyrazic nasza tozsamośc ktora juz posiadamy czy to zawodowa czy prywatna w tej apliakcji. Enteprise APIs

December 12,2013 Pytanie wiec czy mamy jakies pomysly jak to rozwiazac. I oczywiscie pomsyly mamy jako “branza” I to od dluzszego czasu. Z tym ze przechodza one rozne stany I fazy – glownie dlatego ze zmienia sie swiat dookola nas Dygresja – ktos pamieta OpenID? No wlasine – czy go uzywamy – nie? Zmienil sie swiat a OpenID nie bylo wygodne do uzycia. To spowodowalo ze zaniklo. Ale teraz doszlimsy do punktu krytycznego gdzie my jako branza musimy to jakos rozwazac. I rozwiazania powstaly

A gdyby spróbować inaczej December 12,2013 A gdyby spróbować inaczej Identity Provider (IdP) – usługa uwierzytelenienia użytkowników Informacja o tożamości STS – Security Token Service Relaying party (RP) – aplikacja korzystająca z IdP Deleguje uwierzytelnienie do IdP Zaufanie Informacja Wszystkie te rozwiazania o ktorych bedizemy mowic I ktore sa rozwazane łaczy wspolny mianownik – dlaczego programist tworzocy aplikacje ma zajmowac sie obsluga tożsamości, skoro użytkownik już ja posiada? Dalczego aplikacja nie może z niej wprost skorzystać I nie przejmowac sie tym wszystkim co jest związane z utrzymaniem informacji o tożsamości. Taki centralny punkt dla tożsamości użytkownika to Identity provider. Nie jeden ale wielu takich dostawcow. IdP ma za zadanie potwierdzic na zadanie aplikacji informacje o tozsamosci I przygotowac jej reprezetnacje dla aplikacji. Idealnie w kontekscie na jaki wyrazil zgode uzytkownik, czyli uzytkownik musi potwierdzic chec wydania tej informacji I poznac jej zakres. Aplikacja to relaying party – deleguje uwierzytelnie do Idp I polega na tym, że Idp wie jak potwierdzic I przygotowac odpowiednia informacje dla aplikacji. Idealnie w odpowiednim kontekscie. Aplikacja nie musi wiedziec jak uzytkownik sie uwierzytelnil, nie musi wiedziec skad pobrana zostala informacja – liczy sie fakt I zauanie do Idp Sama informacja to zestaw atrybutow opisujacych tożsamosć użytkownika.

podejście pierwsze - enterprise December 12,2013 podejście pierwsze - enterprise SAML = Security Assertation Markup Language oparty na SOAP /XML Standaryzowany przez OASIS wspierany przez rozwiązania SSO i aplikacje enterprise (ale nie tylko) główne zastosowanie Web SSO Act-AS – dostęp do web services Pierwsze powazne podejscie do tematu to protocol SAML. Oparty na SOAP / XML ktory powstal jako rozwiazanie wystandaryzowane przez OASIS SAML realizuje ten pomysl ktory przedstawilem wczesniej – IDP dokonuje oepracji uwierzytelnienia uzytkownika I dostarcza informacji na rzecz aplikacji ktora o taka operacje sie zwraca. Pozwala to na zapewnienie SSO do aplikacji na platformie Web I na kilka innych scenariuszy, miedzy innymi Act-AS czyli delegacje tożasmosci do web-service (odpowiednik API teraz) SAML znalazl swoje miejsce glownie w swiecie enterprise. Tez dlatego ze tworzony byl w zuelnie inej rzeczywistosc, ktora nie byla tak odlegla od nas – to jest raptem kilka lat temu.

SAML – jak działa Identity Provider Relaying party Użytkownik December 12,2013 SAML – jak działa Identity Provider Relaying party Jak dziala SAML? Użytkownik

problemy z SAML relacja 1:1 pomiędzy IdP a RP December 12,2013 problemy z SAML relacja 1:1 pomiędzy IdP a RP Skalowanie w sieci przy rosnącej ilości API \ aplikacji zarządzanie relacjami skomplikowany dla developerów protokoły specyfikacja formatu tokenów wiele profile Act-As - delegacja Zarządzanie – ralacja 1:1 Skalowanie Zarządzanie relacjami Skomplikowany dla devleopero Protokoly \ format Web-Service SOAP \ XML Dygresja ktora naszla mnie w trakcie przygotowywan – mamy nowych dev ktorzy niekoniecznie musza wiedziec co to SOAP Nie identyfikuje kontektu uzytkownika, a raczej inaczej – ustawia go w pre-definiowanym przez relacje zafuania pomiedzy Idp a RP kontekscie.

SAML is not dead December 12,2013 Pomimo swoich Wad SAML nie umarl. Wspiera go wiekszosc aplikacji ktore maja swoje miejsce w enterprise I systemow ktore tam dzialaja. Calkiem niedawno Wsparcie dla SAML oglosilo Office 365 I Amazon web Service, wspiera go Salesforce I Google. Czyli jak widac wszystkie platform, dla ktorych klientem moze bycc jakas organizacja. Saml nie jest dokaldnie typem oferty jaka oczekuje apliakcja mobilna czy startup ktory w tej chwili startuje na potrzeby zwyczjengo end-usera. Ale jak najbardziej mozecie go spotkac I warto o nim pamietac jeszcze chwile tutaj bedize

new kids on the block December 12,2013 Poniewaz swiat sie zmienil to I powstaly nowe stnadardy I teraz w nich upatrujmey przyszlosc w zakresie obslugi tozsamosci w sieci I wszystko wskazuje na to ze zadomowily sie na dluzej. Mowimy o Oatuh 2.0 I OpenID connect . Pytanie – kto robil cos z Oauth 2.0? A kto robil co na plaftformie Facebook albo aplikacje uzyskujaca dostep do Google czy twitter? No wlasnie – jest duza szana ze uzwyalizcie Oauth 2.0/ Od niego wiec zacznijmy

December 12,2013 Oauth powstał w odpowiedzi a rosnącą potrzebę dostep do danych I usług poprzez API. Szacuje sie ze ok 85% API używanych w tej chwili zabezpieczone jest poprzez Oauth. Celem Oauth było dostarczenie prostego w uzyciu protokolu delegacji dostep dla aplikacji do wywolania API w rosnacej skali ekonomii API I aplikacji mobilnych \ naïve apps na urządzeniach mobilnych

OAuth 2.0 Protokół protokołów (framework) Adresuje December 12,2013 OAuth 2.0 Protokół protokołów (framework) Definiuje przepływ informacji Pozostawia swobodę implementacji Adresuje Delegację dostępu Brak wymiany hasła Odwołanie dostępu Nie jest to protokół uwierzytelnienia Po pierwsze to Oauth sam w sobie nie jest ściśle zdefiniowanym protokolem. Oauth definiuje przeplyw informacji I jak powinni zachować sie aktorzy, pozostawiajac szczegoly do implementacji I pozostawiajac dowolnosc w wielu aspektach Dzieki temu jest elastyczny I pozwala na dostosowanie go I uzycie w konkretnym scenariuszu. Z drugiej strony czesto wymaga to implementacji pod konkretnego dostawce. Co wazne – nie jest to protocol uwierzytelnienia. Protok uwierzytelnienia definiuje metode uwierzytelnienia I jego implementacje. Oauth stwierdza ze uwierzytelnienie ma nastapic, nie specyfikuje jednak jak,

OAuth 2.0 – jak działa API: wie kim jest owner kim jest klient December 12,2013 OAuth 2.0 – jak działa Authorization Server (IdP) Resources Server (API) {by ref} {scopes} API: wie kim jest owner kim jest klient kim jest IdP To nie jest uwierzytelnienie. Poniewaz w kroku pozyskania dostep (access token) wystepuje krok potwierdzenia tozsamosci przez authorization server to czesto aplikacje to wykorzystuja. Resource Owner Klient (web site)

OAuth 2.0 – problemy OAuth nie jest protokołem uwierzytelnienia December 12,2013 OAuth 2.0 – problemy OAuth nie jest protokołem uwierzytelnienia dostęp do zasobu i delegacja nie przekazuje informacji o uwierzytelnieniu i tożsamości nie dostarcza informacji o tożsamości wymiana tokenów dostępu delegacja dostępu do API (zasobu) Potencjalne problem -> oprocz tego co na slajdzie – dowolonosc protokolu powoduje ze czest aplikacjie maja obsluge Oauth nastawiona na jedna konkretna implementacje.

OpenID Connect zbudowany na OAuth 2.0 (protocol of protocols) December 12,2013 OpenID Connect zbudowany na OAuth 2.0 (protocol of protocols) protokół federacji Dodaje informację o tożsamości do wymiany wiadomości OAuth 2.0 oparty o format JWT (JSON Web Token) wprowadza userinfo endpoint pobranie informacji o tożsamości pobranie kolejnych tokenów OpenID != OpenID Connect 85% API jest zabezpiecozne przez OAUth

OpenID Connect – jak działa Authorization Server (IdP) Relaying party \ client {scopes} {openid} Użytkownik (przeglądarka)

ID token access token -> przeznaczony dla API ID token -> przeznaczony dla klienta dla kogo wydany -> klient informacje o tożsamości metoda uwierzytelnienia kto go wydał data wygaśnięcia

OpenID Connect: uwierzytelnienie Definiuje przepływ ale nie metodę uwierzytelnienia Pozwala na zastosowanie silnego uwierzytelnienia \ MFA

web finger Web finger – usługa discovery dla RP E-mail jako identyfikator -> joe@example.com

discovery OpenID Connect zawiera specyfikację discovery dla usług December 12,2013 discovery OpenID Connect zawiera specyfikację discovery dla usług

automatyczna rejestracja Rejestracja klienta -> client_id Automatyczna rejestracja z dostawcą OpenID Connect

DIFFERENT

Model oparty o IdP \ AuthZ Server Uniezależnia nas od źródła i implementacji metody uwierzytelnienia Autoryzacja oparta o informacji o tożsamości SAML Informacja o tożsamości \ delegacja OAuth 2.0 Framework dla innych protokołów Delegacja dostępu -> API Economy OpenID Connect “SAML na sterydach” na miarę czasów i wymagań

December 12,2013 get on-board Wszyscy wielcy wchodza w ten obszar I to wspieraja. Nie nalezy ich oczywiscie slepo nasladowac ale to pokazuje ze Identity as service – to juz istnieje. W dwoch wymiarach – uslug dla developerow jak I uslug dla klientow Dla developera to oznaca wygode I skupienie sie na tym co go najbardizej interesuje, oddanie zarzadzania tozsamoscia do zewntetrznego dostawcy Dodatkowo dzieki temu staje sie od niego niezalenzy. Jezeli skorzysta ze stnadardow takich jak OpenID Conenct to w zasadzie dowolny dostawca to wspierajacy jest dla niego partnerem Potencjalne Demo -> zobaczmy jak to pozwala nam skupic sie na tym czego najbardizej chcemu

December 12,2013 get on-board Next big thing … a protokoly takie jak Oauth I OpenID Connect sa najlepszymi kandydatami do tego ze na ich podstawie zostanie oparte zarzadzanie tozsamosci w swiecie IOT

Dziękuję! -> wypełnijcie ankiety ;) twitter: @tonyszko