To już jest… jeszcze nie koniec, ale prawie!, pierwszego, dziewiczego sezonu DevTalk. W poszukiwaniu własnej tożsamości natrafiłem na… eksperta w tej dziedzinie. Ale w kontekście IT, oczywiście.
Dzisiaj przed Wami Tomasz Onyszko. Architekt, od zawsze w branży ;), niezmiennie związany z kwestiami zarządzania tożsamością w sieci. Oprócz tego pisze na firmowym blogu Predica i regularnie gości na grupach pasjonackich oraz krajowych i światowych konferencjach. Od lat “nosiciel” tytułu Microsoft MVP. Na Twitterze: @tonyszko.
Konwersujemy o, jakże by inaczej, zarządzaniu tożsamością i dostępem. Brzmi enigmatycznie? To po prostu: dlaczego username/password jest złe i jak podejść do tych kwestii z innej strony. Dodatkowo Tomek klarownie tłumaczy takie pojęcia jak OAuth i Open ID Connect, które pewnie każdemu obiły się o uszy, ale nie każdy wnikał “jak to działa”. I wreszcie: po przesłuchaniu tego odcinka już nigdy nie powiecie “autentykacja”! :)
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki:
- blog Predica: http://blog.predica.pl
- OpenID Connect: http://openid.net/connect
- OAuth 2.0: http://oauth.net/2
- wprowadzenie do claimsów z bloga Future Processing: http://www.future-processing.pl/blog/introduction-to-claims-based-authentication-and-authorization-in-net
- dobra książka Microsoftu o claimsach: “A Guide to Claims-Based Identity and Access Control” (https://msdn.microsoft.com/en-us/library/ff423674.aspx)
- Identity Server (https://identityserver.github.io/Documentation/) (GitHub: https://github.com/IdentityServer/IdentityServer3)
- blog Dominicka Baiera: http://leastprivilege.com
- blog Vittorio Bertocci: http://cloudidentity.com
- SimpleAuthentication – prosta delegacja uwierzytelnienia do Facebook/Twitter/etc: https://github.com/SimpleAuthentication/SimpleAuthentication
- OAuth.io: https://oauth.io
- Auth0 – https://auth0.com/
- Google Idenity Toolkit: https://developers.google.com/identity/toolkit/
- Azure AD Code Samples: https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx
- Azure AD Authentication Library for .NET: https://msdn.microsoft.com/en-us/library/azure/jj573266.aspx
- https://accounts.google.com/.well-known/openid-configuration
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Mogę się zgodzić, tylko częściowo z rozmówcą. Otóż tabela users jest potrzebna w wielu systemach, gdzie mamy różne uprawnienia dla różnych użyszkodników. Więc o ile identyfikacja może być różna, to jednak sama tabela users jest niezbedna.
@Kaczus
To zalezy… teraz mowie serio. Nie musisz miec uprawnien trzymanych w bazie danych. Moga one byc uzaleznione od jakiegos atrybutu ktory jest juz nadany a ty tylko z niego korzystasz. Mozesz, ale nie musisz. U nas w ostatnich 10 projektach to mozna powiedziec ze cos na ksztalt tabeli users (choc nie zupelnie takiej typowej tabeli) istnieje w 5 projektach. 5 pozostalych nie ma tabeli users bo jest ona kompletnie zbedna a i tak mamy uprawnienia i pewne akcje w aplikacji moga byc wykonywane jedynie przez pewne osoby.
@Kaczus
I bardzo dobrze, że się nie zgadzasz albo inaczej – masz przemyślenia. Po to jest dyskusja.
Co do meritum – dokonujesz tutaj skrótu, ktory jest często wykonywany czyli łączysz uwierzytelnienie z autoryzacją. To o czym piszesz to jest faza autoryzacji, czyli po tym jak już uwierzytelniłeś człowieka (wiesz kto to) to sprawdzasz na co mu pozwalasz (jakie ma uprawnienia). To jak go uwierzytelniłeś … no właśnie, możesz to albo wykonać lokalnie albo oddelegować to gdzieś, gdzie ten użytkownik ma już swoje poświadczenia i kto wie jak potwierdzić że ten użytkownik to on. Lub nawet jeżeli robisz to samodzielnie, to z punktu widzenia aplikacji możesz to zrobić inaczej niż sprawdzając lokalnie login i hasło – możesz mieć swojego własnego małego IdP który zweryfikuje użytkownika ale dla Twojej aplikacji będzie to użycie odpowiedniego protokołu i oddelegowanie tego faktu.
Co do autoryzacji – to już szersza dyskusja. W większości aplikacj w tej chwili posiadają swoje dane do autoryzacji i wykonywane jest to po stronie klienta. Co jest proste w zaimplementowaniu ale czasmi nie jest wystarczajace, np wtedy gdy potrzebne są centralnie zasady autoryzacji lub autoryzacja dynamiczna (np. autoryzacja konkretnej transakcji o danej kwocie itp). Wtedy wchodza rozwiązania takie jak XACML.
Ale jak patrzymy na to z punktu widzenia najczęściej budowanych teraz aplikacji to po to własnie jest OAuth – odsyłasz klienta do serwera autoryzacji z podaniem zakresu do jakiego klient będzie się dostawał (scopes) – serwer autoryzacji odpowiada Ci (1) że zna takiego klienta, (2) do jakich scopes ma on uprawnienia z tych które zażądał. Dostajesz token który takie dane zawiera i na jego podstawie uderzasz do API … i tak dalej. Z samą implementacją OAuth jest kilka problemów ale ogólnie to tak działa .. o czym zresztą rozmawialiśmy.
Więc uwierzytelnienie i autoryzacja. Dane autoryzacyjne po stronie aplikacji – tak, dlaczego nie, ale warto przemyśleć też czy można inaczej, nawet jeżeli będzie to samodzielenie implementował u siebie.
O tożsamości z Tomaszem Onyszko
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
Na początku wielkie dzięki za ciekawy wywiad.
Mam pytanie dotyczące logowania z perspektywy samego użytkownika aplikacji. Czy w przypadku właśnie, kiedy mamy setki haseł (a dobrze wiemy że standardowy user raczej nie używa magagera haseł), lepiej (bezpieczniej) jest logować się do aplikacji poprzez authorisation server dużych korporacji, czy bezpośrednio w aplikacji? Czy w przypadku działania OAuth nie ma tu większych zagrożeń?
Bardzo ciekawy temat. Dużo mi się wyjaśniło w tym temacie. Świetny odcinek!
Krótkie pytanie – z jakiego managera haseł korzystasz (korzystacie)?
Łukasz K,
No to gites :0.
Manager kaseł: KeePass (i Tomek i ja, zresztą ta nazwa pada w rozmowie). Jest jeszcze LastPass, ale jak Tomek na Twitterze ostatnio podlinkował: został właśnie zhackowany: https://twitter.com/tonyszko/status/610545395496824832
@Maciej
Słyszałem właśnie w rozmowie KeePass, ale chciałem się upewnić.
Korzystam z LastPass :/ Właśnie szukam alternatywy heh.
@Jacob
To trochę inaczej:
W aplikacjach dobrze jest używać standardów które już istnieją, i które adresują pewne problemy. Jeżeli z nich będziemy korzystać to będziemy mogli dać użytkownikowi wybór – załóż u nas sobie konto (w końcu dla naszej organizacji czy aplikacji tez możemy stworzyć lokalnie taką usługę jak IdP) czy skorzystaj z jednej z tożsamości które już masz. To nie musi być duża korporacja, to może być dowolna organizacja która będzie wspierała odpowiednie protokoły – taką obietnicę przynajmniej daje nam OpenID Connect.
Zaleta tego że zrobimy to postępując zgodnie z jakimś wzorcem (protokołem) jest taka, że nie wymyślamy całości od nowa i możemy też właśnie skorzystać, albo przynajmniej dać wybór użytkownikowi jakiej tożsamości chce użyć w naszej aplikacji. Jeżeli będzie mógł skorzystać z tożsamości którą już posiada to mamy benefit dla użytkownika (nie musi zakładac dodatkowego konta itp) jak i dla nas (nie musimy obsłufiwac w aplikacji tych wszystkich rzeczy związanych z zarządzaniem kontem i hasłem).
Jeżeli chodzi o OAuth to jest to jeszcze odrębna sprawa – (1) OAUth nie jest protokołem uwierzytelnienia. (2) z tym się wiąże to o czym wspominałem, że nie jest też mocno wyspecyfikowany, czyli ze na przykład nie jest powiedziane jak weryfikować tokeny, nie ma wskazane wprost jakie metody uwierzytelnienia są dozwolne itp. Więc użycie OAuth czy OpenID Connect nie wpływa jakoś bezpośrednio na poprawę bezpieczeństwa. Jednak wpływa (1) na to co robimy w swojej aplikacji, a jeżeli robimy mniej to też ograniczamy swoje zagrożenia (nie przechowujemy danych które mogą wyjść na zewnątrz itp), jak i wpływa na użytkownika – ma pojedynczy (czy też mniejszą liczbę) wpis którym zarządza. Na bezpieczeńtwo użycia OAuth wpływa to jak Authz server wykonuje uwierzytelnienie, czy jest możliwe i jak zweryfikowanie tokenu, jak aplikacja przechowujei zabezpiecze otrzymane tokeny (w szczególności refresh token) itp – tutaj o wiele lepiej jest zdefiniowany OpenID Connect.
Updated: DevTalk – Programistyczny głos w Twoim domu
http://groopmark.com/link/details/181/devtalk-programistyczny-glos-w-twoim-domu?cid=11
@Tomek
Wielkie dzięki za obszerne wyjaśnienie. Na pewno temat jest bardzo ciekawy i warty zgłębienia.
Pozdrawiam.