Zarządzanie tożsamością Promotor: Prof. dr hab. Zbigniew Kotulski 17 kwietnia 2007 Dominik Zasiewski

Zarządzanie tożsamością Konspekt prezentacji I.Cele systemów zarządzania tożsamością II.Podział systemów zarządzania tożsamością III.Systemy oparte o federacje tożsamości IV.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 IdP SP Kalendarz Serwis kadrowy Menadżer projektu Poczta Bank Operator kom. Profil w pracy Profil domowy Kowalski SP Pogoda SP Agregator SP

Zarządzanie tożsamością III. Globalne kółko zaufania według Nokia oraz SUN

Liberty Alliance Projekt ( III. Cykl federacji Proces rejestracji użytkowników Poza specyfikacją Wymiana informacji (Idp – SP) Federacja SSO Jednokrotne wylogowanie się Zakończenie federacji Rejestracja pseudonimów

Zarządzanie tożsamością III. Przebieg procedury łączenia kont, oraz federacji tożsamości w kółku zaufania według Liberty Alliance Internauta (IdP)Serwis SP 1) Użytkownik sygnalizuje chęć federacji tożsamości 2) Internauta loguje się do dostawcy tożsamości uwierzytelnienie IdP zapisuje swoją wizytówkę – ciasteczko stronie Internauta loguje się do serwisu Czy chcesz łączyć to konto w ramach federacji? Serwis wykrywa wizytówkę IdP - ciasteczko uwierzytelnienie Tak Serwis przekierowuje Internautę do IdP Żądanie potwierdzenie statusu uwierzytelnienia uwierzytelnienie IdP generuje asercję SAML potwierdzając ą tożsamość Internauty Przekierowanie do SP Asercja SAML Przetwarzanie otrzymanej asercji. Uzgadnianie pseudonimó w z IdP SOAP Strona serwisu. start pracy

Zarządzanie tożsamością III. Łączenie kont w relacjach IdP – SP konto IDP Łączenie kont Alias: mr3tTJ Domain: SP1.com Name: dTvIiR Alias: xyrVdS Domain: SP2.com Name: pfk9uz konto SP1 konto SP2 Łączenie kont Alias: dTvIiR Domain: IDP.com Name:mr3tTJ Łą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:

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  Tokeny to losowe numery (zapobiega to ew. śledzeniu, nie da się ich także łączyć ze sobą – pomiędzy różnymi serwisami) Kolejne logowania  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