Identity Management Systems

Transcript

Corso di Sicurezza 2
A.A. 2007/08
Eugenio Rustico
Sommario
▶ Qualche
definizione
 Identità digitale, IMS
▶ IMS aziendali
 Caratteristiche
▶ Single Sign On
▶ User-centric IMS
 Identity selectors
 OpenID
Sicurezza 2 - Identity Management Systems – Eugenio Rustico
Identità digitale
“The digital representation of a set of claims
made by one digital subject about itself or
another digital subject.”
Fonte: wikipedia
Intuitivamente: la rappresentazione nel mondo
digitale della nostra identità “reale”
Identità digitale
Identità digitale
●
●
●
Reale↔digitale è di norma una relazione unoa-molti
Quella digitale è univoca quando associata ad
un preciso contesto (namespace)
Identità federata: l'insieme delle identità digitali
di un soggetto reale, memorizzate in più IMS
distinti, associate tra loro da un token
(username o identificativo)
IMS
Identity Management:
“Providing the right people
with the right access
at the right time”
Completo ma non corretto: è implicito negare a
tutti gli altri!
In genere, più corretto “subjects” che “people”
IMS
●
●
●
Il sistema di gestione delle identità non è il
sistema di autenticazione, ma collabora
strettamente con esso.
Ogni sistema operativo moderno ha un
sottosistema di gestione delle identità più o
meno flessibile (es. Unix)
Le caselle email che permettono di gestire
diversi alias sono un primitivo IMS
IMS

Aziendali/personali

Centralizzati/decentralizzati
Provisioning: creazione identità digitali, modifica
delle credenziali
Deprovisioning: cancellazione di credenziali o
intere identità digitali
Sommario
▶ Qualche
definizione
▶ IMS aziendali
 Caratteristiche
▶ Single Sign On
 OpenID
IMS aziendali
Non prodotti preconfezionati, ma soluzioni
personalizzate.
Quali caratteristiche sono desiderabili?
Provisioning e deprovisioning automatizzati
✔ Interfacce web-based
✔ Revoche immediate
✔ Coerenza con le politiche aziendali
...
✔
IMS aziendali
...
✔ Processi di approvazione seriali e paralleli
✔ Integrazione con sistemi legacy
✔ Delega di autorità, manuale o automatica dopo
un timeout
✔ Modifica dinamica dei ruoli
✔ Flessibilità nella gestione delle credenziali
✔ Programmazione temporale di provisioning e
deprovisioning
...
IMS aziendali
...
✔ Rilevazione cambiamenti manuali,
approvazione, aggiornamento automatico
✔ Notifiche automatiche
✔ Flessibilità nei ruoli: ruoli multipli, gerarchici,
ereditarietà
✔ Integrazione con diverse topologie di rete
(firewall, NAT)
✔ Gestione delle password (rinnovo automatico,
dizionari di esclusione, regole di validità...)
...
IMS aziendali
...
✔ Compatibilità con DBMS (MySQL, Oracle, MS
SQL Server...) e web applications (Tomcat,
Websphere...)
✔ Scalabilità
✔ Rilevamento conflitti ruoli/politiche
✔ Auditing & reporting
✔ Approccio federativo e standard compliance
(SAML, LDAP, Liberty Alliance, OpenID, SPML,
XACML...)
✔ Single Sign On
Single Sign On
“Single sign-on (SSO) is a method of access
control that enables a user to authenticate
once and gain access to the resources of
multiple software systems.”
Fonte: wikipedia
Meglio “enterprise reduced sign-on”, in quanto è
difficilmente attuabile senza omogeneità delle
infrastrutture
Single Sign On
Vantaggio: semplificazione

Una “password” da ricordare

Infrastruttura hw/sw semplificata
Possiamo concentrare le risorse su di un'unica
operazione (e.g. smartcard)!

Single Sign On
Svantaggio: centralizzazione
Può essere come autenticare un terminale, non
un utente


E se mi rubassero proprio quella password?

Auspicabile single sign off automatico
Single Sign On
Il SSO non è una prerogativa dei sistemi
aziendali...
Sul web è in genere implementato tramite le
sessioni (stesso web server) o i cookies
Single Sign On
Tecniche
Server di autenticazione centralizzato (es.
siti multiservizio come Google)


Rilascio di un token (es. Kerberos)
Identity providers decentralizzati (es.
OpenID)

Completamento automatico di form
(Enterprise-Single Sign On)

Sommario
▶ Qualche
definizione
▶ IMS aziendali
 Caratteristiche
▶ Single Sign On
 OpenID
IMS personali
User-centric IMS: è l'utente a decidere le
politiche da adottare.
●
Di chi mi fido?
●
Quali informazioni sono disposto a rilasciare?
●
Chi sa cosa sto facendo?
A livello applicativo: identity selectors (Windows
CardSpace, DigitalMe, Higgins Project...)
IMS personali
Information Cards
Information Card: la rappresentazione visuale di
una identità digitale
Nome Cognome
Società
Mansione
Public RSA key fprint: 0123456789ABCDEF
Username
Email
Password: **********
L'utente seleziona quale information card
mostrare quando un servizio richiede delle
credenziali
OpenID
OpenID
Da Brad Fitzpatrick, il creatore di LiveJournal.
Dal sito ufficiale:
“For geeks, OpenID is an open, decentralized, free
framework for user-centric digital identity. OpenID takes
advantage of already existing internet technology (URI,
HTTP, SSL, Diffie-Hellman) and realizes that people are
already creating identities for themselves whether it be at
their blog, photostream, profile page, etc. With OpenID you
can easily transform one of these existing URIs into an
account which can be used at sites which support OpenID
logins.”
OpenID
OpenID non fornisce un vero e proprio
meccanismo di autenticazione, bensì una forma
di delega di autenticazione ottenuta tramite altri
protocolli.
L'utente decide quali credenziali presentare a
chi, e si identifica con un solo identificativo (un
URL).
La novità è che l'utente può anche scegliere chi
sia il proprio “provider di identità”.
OpenID
In sintesi
1. URL OpenID
End user
2. Redirect presso OP
RP
5. Servizio
OP
4. Conferma autenticazione
3. Autenticazione
= indirect message (redirect via browser)
OpenID
Un provider OpenID: MyOpenID
OpenID
OpenID
OpenID
OpenID
OpenID
OpenID
Come evitare che un OP o una RP possano
tracciare tutto ciò che facciamo?
1. Utilizziamo OP differenti
2. Deleghiamo, e usiamo come URL qualsiasi
pagina web che possiamo modificare:
<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://eugenior.myopenid.com/" />
3. Possiamo diventare anche noi degli Identity
Provider: esistono librerie per molti linguaggi
OpenID
OpenID
OpenID
Relying party (RP) – entità che desidera
verificare l'identità dell'utente

Identity Provider (OP) – entità che offre un
servizio di autenticazione compatibile con
OpenID

End user – colui che chiede un servizio presso
la relying party, e ha bisogno di autenticarsi
presso di essa

OpenID
Direct Request – messaggio scambiato
direttamente tra RP e OP tramite HTTP POST

Indirect Request – messaggio scambiato
tramite il browser dell'utente (redirezione HTTP o
form HTML)

OpenID
1. User  RP: {openid_identifier}
Nella form della pagina di login dell'RP, il campo
destinato all'OpenID deve avere nome
openid_identifier
OpenID
2. RP: normalization dell'openid_identifier e
discovery dell'OP Endpoint URL
In pratica, l'RP analizza l'indirizzo fornito
dall'utente e cerca l'URL esatto dell'OpenID
provider (necessario, ad esempio, in caso di
delega)
OpenID
3. RP  OP: {ns, mode, assoc_type,
session_type}
ns: “http://specs.openid.net/auth/2.0”
● mode: “associate”
● assoc_type: “HMAC-SHA1” o “HMAC-SHA256”
● session_type: “no-encryption”, “DH-SHA1” o
“DH-SHA256”
●
OpenID
Opzionali per Diffie Hellman: dh_modulus,
dh_gen, dh_consumer_public
Modulo predefinito:
DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB
OpenID
4. OP  RP: {ns, assoc_handle, assoc_type,
session_type, expires_in [...]}
se l'OP è in grado di memorizzare l'handle e
mantenere una sessione stateful; in tal caso, OP
ed RP si scambiano un segreto con DiffieHellman. Altrimenti:
4. OP  RP: {ns, error, error_code [,...]}
con error_code = “unsupported_type” per una
sessione stateless
OpenID
Authentication Request
5. RP  OP: {ns, mode, claimed_id, [identity,
assoc_handle, return_to, realm]}
mode: "checkid_immediate" o "checkid_setup"; il
primo per richiedere una autenticazione senza
intervento dell'utente (ad es. per pagine AJAX), il
secondo per una autenticazione interattiva
Nota: questo messaggio è una indirect request
OpenID
6. OP  User: autenticazione
Dalle specifiche OpenID:
“The manner in which the end user authenticates
to their OP and any policies surrounding such
authentication is out of scope for this document.”
OpenID
Authentication Request
Se siamo in presenza di una positive assertion:
7. OP  RP: {ns, mode, op_endpoint, claimed_id,
identity, return_to, response_nonce,
invalidate_handle, assoc_handle, signed, sig}
mode: ”id_res”
● response_nonce: deve iniziare con la data
corrente del server
● signed: elenco dei campi inclusi nella firma
● sign: firma (stringa base64 encoded) tramite
HMAC e segreto condiviso (per sessioni stateful)
●
OpenID
Se, invece, siamo in presenza di una negative
assertion (autenticazione fallita):
7. OP  RP: {ns, mode}
mode: ”setup_needed” se in risposta ad una
immediate request (si richiede una nuova
autenticazione in modalità interattiva), “cancel”
altrimenti
●
OpenID
Se la sessione era stateless, non abbiamo ancora
finito: l'RP non possiede un segreto condiviso con
cui verificare la firma. Manda dunque una direct
request (via HTTP POST) all'OP uguale al
messaggio appena ricevuto (tranne nel il campo
mode, che deve essere “check_authentication”):
8. RP  OP: {[...], mode, [...]}
L'OP risponde true/false con una direct request:
9. OP  RP: {ns, is_valid, invalidate_handle]}
OpenID
Ogni messaggio può contenere dei campi
aggiuntivi (extensions) per veicolare informazioni
addizionali (ad es. il metodo di autenticazione
usato)
OpenID
Considerazioni
Discreta explicitness (es. in Authentication
Response), ma poca attenzione per la freshness
(una sola nonce in tutto il protocollo)
●
La verifica al passo 8 ha senso solo se la
connessione è sicura (TLS/SSL)
●
Le indirect request sono facilmente alterabili
dall'utente (dal browser dell'utente!)
●
OpenID
Le specifiche raccomandano l'utilizzo di
crittografia al livello sottostante (TLS in
particolare), ma non è mandatory
●
Se il DNS non è sicuro, o si altera la fase di
discovery, un attaccante può impersonare
facilmente un OP
●
Diffie Hellman deve essere in un tunnel sicuro
per evitare MITM
●
OpenID
OpenID
Contrastare il phishing
Chiedere all'utente di digitare manualmente
l'indirizzo dell'OP, invece di effettuare un redirect
●
●
●
Plugins per il browser (es. SeatBelt di Verisign)
Un mostro durante l'autenticazione ci salverà!
OpenID
OpenID
OpenID
“Non prenderà mai piede!”
OpenID
“Non prenderà mai piede!”
AOL
● Microsoft
● LiveJournal
● Technorati
● Sourceforge
● Yahoo!
● Verisign
● Google
● ...
●
Il futuro del web 2.0?
...
Fine
...that's all, folks!
Q?

Identity Management Systems

Transcript

Documenti analoghi

affascinante rustico riattato Valle Calanca

verdemare - Associazione "PERCORSI"

Anche quest`anno la Pasquetta ci invoglia a trascorrere una bella

scheda tecnica corso

l` uso performante del web: comunicare e

AGENZIA INVESTIGATIVA SYRIA SERVICE DI SECLI` ELVIO

BUONO SCONTO

Cucina tradizionale - Comune di Valle dell Angelo