Analiza zarządzania danymi osobowymi w formie elektronicznej

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ą