Zarządzanie tożsamością Promotor: Prof. dr hab. Zbigniew Kotulski 17 kwietnia 2007 Dominik Zasiewski Konspekt prezentacji I. II. III. IV. Cele systemów zarządzania tożsamością Podział systemów zarządzania tożsamością Systemy oparte o federacje tożsamości Systemy scentralizowane wokół użytkowników Zarządzanie tożsamością I. Cele systemów zarządzania tożsamością Nowa funkcjonalność SSO (Single Sign On), współdzielenie informacji Bezpieczeństwo Współpraca z różnymi standardami Skalowalność i elastyczność Ochrona prywatności Zarządzanie tożsamością I. Wytyczne do oceny systemów zarządzania tożsamością Zarządzanie tożsamością II. Podział systemów zarządzania tożsamością Single - domain Np.. systemy działające w obrębie jednej korporacji Cross - domain Np.. systemy (platformy) działające w Internecie, lub pomiędzy różnymi korporacjami Zarządzanie tożsamością II. Podział systemów zarządzania tożsamością – Single domain Systemy: Kerberos, Active Directory (protokół LDAP) Funkcjonalność: SSO Wady: brak skalowalności, brak zgodności pomiędzy różnymi systemami brak prywatności (chociaż to nie jest w zasadzie wymogiem systemów z tej kategorii) Zarządzanie tożsamością II. Podział systemów zarządzania tożsamością – Cross domain Dostępne technologie: Systemy oparte o standardy organizacji Liberty Alliance – koncepcja Federacji (SAML) Microsoft CardSpace (InfoCards) OASIS Yadis / OpenID Zarządzanie tożsamością III. Federacja tożsamości Pojęcia związane z federacją tożsamości Federacja Circle of Trust (Kółka zaufania) Elementy kółka: IdP (Identity Provider) – dostawca tożsamości SP (Service Provider) lub Relying Party - usługodawca Pseudonimy (asercje SAML) Różne identyfikatory tej samej tożsamości u dostawców tożsamości Zarządzanie tożsamością III. Kółka zaufania – federacja tożsamości Kalendarz Profil w pracy SP SP IdP Serwis kadrowy SP Menadżer projektu Pogoda SP Kowalski SP SP SP Poczta SP Agregator IdP SP Profil domowy Zarządzanie tożsamością SP Bank Operator kom. III. Globalne kółko zaufania według Nokia oraz SUN Zarządzanie tożsamością III. Cykl federacji Proces rejestracji użytkowników Wymiana informacji (Idp – SP) Poza specyfikacją Federacja Rejestracja pseudonimów SSO Jednokrotne wylogowanie się Zakończenie federacji Liberty Alliance Projekt (www.projectliberty.org) III. Przebieg procedury łączenia kont, oraz federacji tożsamości w kółku zaufania według Liberty Alliance Internauta (IdP) Serwis SP 1) Internauta loguje się do dostawcy tożsamości uwierzytelnienie Użytkownik sygnalizuje chęć federacji tożsamości IdP zapisuje swoją wizytówkę – ciasteczko stronie 2) Internauta loguje się do serwisu uwierzytelnienie Czy chcesz łączyć to konto w ramach federacji? Tak Żądanie potwierdzenie statusu uwierzytelnienia uwierzytelnienie Przekierowanie do SP Serwis wykrywa wizytówkę IdP ciasteczko Serwis przekierowuje Internautę do IdP IdP generuje asercję SAML potwierdzając ą tożsamość Internauty Asercja SAML SOAP Strona serwisu. start pracy Zarządzanie tożsamością Przetwarzanie otrzymanej asercji. Uzgadnianie pseudonimó w z IdP III. Łączenie kont w relacjach IdP – SP konto SP1 pickwick@sp1 Łączenie kont konto IDP dominik@idp Alias: dTvIiR Domain: IDP.com Name:mr3tTJ Łączenie kont Alias: mr3tTJ Domain: SP1.com Name: dTvIiR konto SP2 domino@sp2 Alias: xyrVdS Domain: SP2.com Name: pfk9uz Łączenie kont Alias: pfk9uz Domain: SP2.com Name: xyrVdS Zarządzanie tożsamością III. Microsoft CardSpace (InfoCards) Standardowy wygląd interfejsu do wyboru kart reprezentujących tożsamość Możliwość generowania identyfikatorów tożsamości Wsparcie wielu standardów, w szczególności Liberty Alliance Technologia docelowo ma być obojętna na metody uwierzytelniania preferowane przez różne serwisy Zarządzanie tożsamością III. Microsoft CardSpace (InfoCards) Źródło: http://msdn2.microsoft.com/en-us/library/aa480189.aspx Zarządzanie tożsamością III. Yadis / OpenID Umożliwia SSO, ale nie gwarantuje innych funkcjonalności (np.. z dystrybucją parametrów tożsamości: preferencji etc.) Logowanie przy pomocy adresu URL będącego identyfikatorem tożsamości Integracja z Firefox’em v.3 i Windows Vista. Zarządzanie tożsamością III. Wady systemów wymagających interakcji IdP przy każdej transakcji uwierzytelnienia wąskie gardło architektury (wydajność) wrażliwość na ataki DoS (blokady dostępu) naruszenie zasad ochrony prywatności IdP jest świadomy, kto i kiedy korzysta z jakich serwisów Zarządzanie tożsamością IV. Systemy scentralizowane wokół użytkowników Systemy oparte o dodód posiadania – „Proof of possesion” Credentica’s U-Prove Zarządzanie tożsamością IV. Credentica’s U-Prove (Faza incjacji) Użytkownik uzyskuje listę tokenów podpisanych przez IdP, każdy do innego serwisu w ramach federacji IdP nie zna identyfikatorów w tokenach, które podpisuje Tokeny zawierają ukryty, unikalny identyfikator tożsamości, który nigdy nie zostaje odkryty Tokeny mogą posiadać dodatkowe informacje o tożsamości Tokenami zarządza aplikacja kliencka (np.. Smart Card) Zarządzanie tożsamością IV. Credentica’s U-Prove (Faza incjacji) Źródło: „Secure User Identification Without Privacy Erosion”, Stefan Brands Zarządzanie tożsamością IV. Credentica’s U-Prove (Uwierzytelnienie) Proces inicjacji w serwisie – połączenie tokena z kontem użytkownika Kolejne logowania Tokeny to losowe numery (zapobiega to ew. śledzeniu, nie da się ich także łączyć ze sobą – pomiędzy różnymi serwisami) Okazanie tokena Wygenerowanie dowodu posiadania klucza prywatnego ukrytego w tokenie SSO – poprzez jednokrotne uwierzytelnienie na karcie (aplikacji zarządzającej) Zarządzanie tożsamością IV. Credentica’s U-Prove (Współdzielenie informacji) Źródło: „Secure User Identification Without Privacy Erosion”, Stefan Brands Zarządzanie tożsamością Pytania Zarządzanie tożsamością