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… Read more »
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… Read more »
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.