Un altro building block del Framework 3.0 si chiama CardSpace ed ha l'ambizione di risolvere uno dei problemi più ricorrenti della quasi totalità delle applicazioni sia internet sia intranet: l'autenticazione utente. I problemi correlati all'autenticazione sono di diversa natura: da una parte la difficoltà dell'utente nel gestire elenchi di username e password, dall'altra la sempre crescente necessità di evitare l'hacking delle password, o ancora la tipologia di informazioni che un utente vuole rivelare di sé a seconda del contesto, fino ad essere anche un semplice utente anonimo; ed infine la necessità di contemplare autorità di autenticazioni differenti a seconda del contesto. Se nel passato Passport ha fallito la sua missione, CardSpace affronta in modo totalmente differente il problema rendendosi fruibile cross-browser e cross-platform per costruire un sistema universale di identificazione nel pieno rispetto della privacy.

1. Email: malta@vevy.com
Blog: http://blogs.ugidotnet.org/raffaele
MVP Profile: http://mvp.support.microsoft.com/profile/raffaele
Visual Developer Security MVP
Raffaele Rialdi, Vevy Europe

2. Agenda
1. La teoria
2. La tecnologia
3. L'implementazione

3. Crisi di identità
• Problemi di privacy
– Identificare pur restando anonimi (forum, chat, ...)
– Identificare in modo certo (banche, sportelli
virtuali)
• L'identità cambia a seconda del contesto
– Identità virtuali diverse per ogni dominio non in
trust
– Identità virtuali spesso differenti da quella fisica
• L'identità custodita da un sito A potrebbe
essere riutilizzata dall'utente nel sito B
– Il sito A potrebbe usare la password all'insaputa
dell'utente
• Password deboli o difficili da ricordare
User/Pwd
PKI
X.509
PKI
X.509
Vulnerabile
Costoso
Difficile
....

4. Si parla di identità
• È un insieme di informazioni che descrivono in
qualche modo un utente o una entità
• Le applicazioni usano queste informazioni per
– Identificare in modo univoco (nel proprio dominio)
– Autorizzare ciò che l’utente può fare nell’applicazione
– Personalizzare il contenuto erogato all’utente/entità
• Il contenitore sulle informazioni relative all’identità è
normalmente chiamato “Token”
– Il formato cambia a seconda del metodo di autenticazione

5. Leggi dell'identità 1, 2, 3
1. User Control and Consent
L'utente deve essere consapevole quando viene identificato e
quali informazioni vengono rivelate
– Windows Authentication e Passport non rispettano questo requisito
2. Minimal disclosure for a constrained use
L'identificazione deve avvenire fornendo solo le minime
informazioni necessarie
– Least identifying information
3. Justifiable Parties
Il sistema di identificazione deve coinvolgere solo le parti che
sono coinvolte nel dialogo
– Passport implicava l'identificazione da parte di Microsoft anche per su siti
non Microsoft
http://www.identityblog.com

6. Leggi dell'identità 4, 5
4. Directional Identity
L'identità deve essere direzionale. Se è omnidirezionale è
pubblica a tutti. Se è monodirezionale è contestuale a quel server
– Il provider delle identità deve supportare sia identità pubbliche che
private
– L’utente non sempre desidera che il server a cui si collega possa rivelare
informazioni su di se
5. Pluralism of operators and technologies
È necessario un metasystem
Un utente può avere più identità da spendere in contesti
differenti (banche, forum, sportelli comunali, ...) e
l'interoperabilità tra provider di identificazione deve essere
possibile
http://www.identityblog.com

7. Leggi dell'identità 6, 7
6. Human Integration
L'essere umano deve poter gestire e scegliere
l'identità in modo chiaro e semplice. Il canale
uomo-macchina è difficile da proteggere.
– password difficili da ricordare e facili da trovare o sniffare
7. Consistent experience across contexts
L'utente deve poter scegliere l'identità in modo
semplice e trasparente a prescindere dal contesto
(tecnologie e provider coinvolte in quel contesto)
http://www.identityblog.com

8. Identity Metasystem
• Consiste nell’uso di una serie di protocolli standard
(WS-*) che permettono di far dialogare tre attori:
– Subject: l'utente o il servizio che deve dimostrare la
propria identità
– Relying Party (RP): il sito web/servizio che deve
identificare chi si collega
– Identity Provider (IP): l'entità che genera il token con le
informazioni e che ne garantisce la veridicità
• Il Security Token Service (STS) permette di convertire
un token in un altro formato o trasformare i claim
• Il security token è espresso nel formato standard
SAML (Security Assertion Markup Language)

9. I protocolli standard
• WS-SecurityPolicy
– descrive il token di sicurezza e
i claim richiesti dalla policy
• WS-MetadataExchange
– permette di richiedere e
ricevere le policy
• WS-Trust
– protocollo per richiedere e
ricevere il token (STS)
• Request for a Security Token (RST)
• Request for a Security Token Response (RSTR)
• Gli Identity Provider hanno al loro interno un Security Token Service (STS)
• Cardspace (cioè la gestione dell'interfaccia utente) è "ignorante" nei
confronti dei formati dei token
Security
Token
Service
WS-Security
Policy
Kerberos SAML
Security
Token
Service
WS-Security
Policy
x.509 Custom
Identity
Provider
Relying
Party
Identity
Provider
Relying
Party
Identity
Selector
Subject
WS-Trust, WS-MetadataExchange

10. I claim (asserzioni)
• Chi ci autentica ha bisogno di asserzioni che servono per il
processo di autorizzazione
• Alcuni claim per Raffaele Rialdi
– È uno developer
– È sposato
– Ha ricevuto l'award MVP
– Ha un blog all'indirizzo http://blogs.ugidotnet.org/raffaele
• L'identità digitale di un soggetto è data da un insieme di
asserzioni fornite in modo sicuro e verificabile da un provider
di identità

11. Role Claim based authentication
• I ruoli forniscono diritti agli utenti per eseguire azioni o accedere a risorse
– Presuppone di identificare l'utente e poi verificare se ha un certo diritto
– Il Principal di .NET incapsula utente e rispettivi ruoli
• I Claim sono asserzioni che viaggiano all'interno del token
– La loro veridicità dipende dall'Identity Provider
– Anche una carta di identità può essere falsa, nonostante il suo IP sia credibile
• È veramente necessario identificare un utente per assegnargli un diritto?
– Per verificare l'età di una persona non è necessario conoscerne il nome
• I token di accesso di Windows
– non sono stati progettati per essere cross-platform
– sono erogati da sistemi operativi (i claim possono essere erogati anche da
altre entità)
– I SID e le ACL nei token sono utili solo all'interno dell'OS. I Claim hanno
significato ovunque il loro Identity Provider sia trusted

12. Agenda
1. La teoria
2. La tecnologia
3. L'implementazione

13. Cos'è Cardspace?
• Cardspace è l'implementazione Windows per la scelta delle
Infocard che rappresentano le identità dell'utente
• I vantaggi di Cardspace sono
– Rendere all'utente semplice ed economico l'uso dei certificati digitali
(PKI)
– Niente più username/password
– Addio Phishing
• Mono è in Work-in-progress su Cardspace
• Firefox ha un plugin funzionante
• Linux ha un Identity Provider di PingIdentity.com

14. Interazione uomo - PC
• Niente più password, solo "Card"
• UI isolata in un altro desktop
• L'infrastruttura completa comprende:
– Il motore principale (Infocard.exe)
• gira come Localsystem, dialoga con UI via RPC
• Include un Identity Provider locale
– L'interfaccia utente di CardSpace (icardgt.exe)
• gira con l'account utente
– Un control panel applet (InfoCardCpl.Cpl)
– I componenti per aprire la UI da IE7 e WCF

15. Le Infocard
• Contengono metadati sui Claim compilati, non i
valori effettivi
• I dati delle Infocard non escono mai dal PC (se non
quando sono esportate dall'utente)
• È l'utente a chiedere all'IP il token e a passarlo, solo
se vuole, alla RP
– Il token non è usabile neppure dal Subject ma transita solo
tramite l'utente
– Il Subject può chiedere un secondo token di "preview" per
verificare le informazioni prima di inviarle

16. Le Infocard
• Un Infocard store per user (Cardspace.db)
• Le ACL dello store abilitano solo Localsystem
• Criptato due/tre volte con:
– Machine Key. Se lo store è copiato su un'altra installazione è
inutilizzabile
• In caso di crash recovery le card sono perse. Backup!!!
– User Key (basato sulle credenziali utente). Se l'utente non è loggato, la
chiave non è neppure presente sulla macchina
• Se la password viene resettata, le card sono perse. Backup!!!
– Pin. Se l'utente vuole, può proteggere ogni card con un pin
• Il backup esporta le card criptandole con una password
chiesta al momento dell'esportazione
Users<user>AppDataLocalMicrosoft CardSpace Vista
Documents and Settings<user>Local SettingsApplication DataMicrosoft CardSpace XP/2K3

17. Contenuto di una Infocard (.crd)
• Uno o più URL dell'indirizzo IP dell'STS
– Necessario per recuperare il Security Token che contiene i
Claim
• I tipi di Claim che saranno contenuti dentro il
Security Token
– L'IP li cripta con la chiave pubblica della Relying Party
• I tipi di Security Token creabili dall'Identity Provider
• I valori dei Claim sono sempre e solo custoditi dentro
l'Identity Provider

18. Self issued cards
• L'utente è Identity provider di se stesso
• È lo scenario più diffuso in internet
– Forum, community, siti aziendali, ...
• I Claim sono garantiti dall'IP e quindi non necessariamente
"veri"
• La distinzione tra registrazione iniziale e login non ha più
senso
– Cardspace ci ricorda quali cards sono state usate su un sito
Subject Relying Party

19. Managed cards emesse da RP
• L'Identity Provider è il sito web / servizio
• Scenario comune dove l'utente possa accedere solo dopo
approvazione della relying party
– Listini rivenditore, siti come ebay, banche, ...
• I Claim sono stabiliti da RP e perciò affidabili
• La RP deve erogare una cards al Subject prima che questo
possa accedere
Subject Relying Party

20. Managed cards con IP indipendente
• La Relying Party deve fidarsi dell'Identity Provider
– Cardspace può nascondere all'IP l'identità della RP
• Scenario dove una sola card abilita più relying party
– Equivalente di una "carta di identità"
– Siti governativi, aziende associate ("federate"),
• I Claim sono affidabili
• La IP deve erogare una card al Subject
Subject Relying Party

21. Subject
Relying Party
1. Richiesta di
accesso al sito
2. Risposta con requisiti
di autenticazione
3. filtro delle card / IP
che soddisfano RP
4. scelta della card
con Cardspace
5. Richiesta
Token
6.
7. Token ok?
8. Token di autenticazione a RP

22. STS
• Active Directory Security Token Service (AD/STS)
– usa kerberos
• Linux STS (PingIdentity.com)

23. Self issued cards
• Le personal cards possono avere solo 12 Claim:
– GivenName, Surname, EmailAddress, StreetAddress, Locality,
StateOrProvince, PostalCode, Country, PrimaryPhone, DateOfBirth,
Gender
– PrivatePersonalIdentifier (PPID, non appare nella UI)
• PPID viene generato la prima volta che viene usato
• PPID viaggia dentro il token criptato e non è intercettabile
– RP lo legge in chiaro
• PPID non viene mostrato all'utente (Social Engineering)
• PPID è differente per ogni Relying Party
– RP non può usare il PPID per rubare info su altri siti
• Quindi PPID è già più sicuro di una password, ma ...

24. Private Personal Identifier (PPID)
• Se l'hacker ruba il PPID alla relying party
• Se l'hacker si scrive un suo Identity Provider
• Se l'hacker genera una propria card con quel PPID
• Soluzione: Non usare PPID ma una combinazione tra
PPID e la public key dell'Issuer (l'Identity Provider)
• Come: In TokenProcessor.cs viene esposta la
proprietà UniqueID che combina queste due cose

25. PPID
• L'unico Claim di una personal card che l'utente non ha
modo di modificare
• Derivato dalla master key del certificato SSL
– Se il certificato è EV, usa Organization, Location, State, Country
– Se il certificato è standard, usa il campo subject di tutte le
certification authority concatenate
– Quindi il PPID è sempre differente, da website a website
• La classe TokenProcessor espone una proprietà
(UniqueID) che è l'hash di PPID e la public key dell'issuer

26. Prerequisiti: certificato SSL
• Cardspace richiede un certificato SSL sul webserver/servizio
• La certificate authority deve essere valida e la certificate revocation
list deve essere raggiungibile
– Commerciale (indispensabile per Internet)
• Certificato Standard: ~18 … 250$ / anno
• Certificato Extended Validation (EV): ~400 … 900$ / anno
– Win2K3 Certificate Authority per Intranet / Test
– OpenSSL Certificate Authority per Intranet / Test
• Chi, come, cosa, ... sui certificati
– http://technet2.microsoft.com/windowsserver/en/library/fb3df0cd-0aae-
472b-9e9c-bb8ca878bc341033.mspx
– http://snipr.com/1nbn9

27. Certificati di test
• Affinché i certificati siano validi è necessario che:
– La Certificate Authority sia valida. Es: Adatum.com
– Il certificato server sia valido. Es: Fabrikam.com
– La revocation List sia disponibile. Es: Adatum.crl
– Il file Hosts mappi su localhost la Adatum e Fabrikam
• One-time WCF Setup
– http://msdn2.microsoft.com/en-us/library/ms751527.aspx
– Tools: Fx3SamplesWCF_SamplesSetupCS
• Cardspace Certificates Setup
– http://msdn2.microsoft.com/en-us/library/aa967570.aspx
– Tools: Fx3SamplesCardSpace_SamplesCreatingManagedCardsCS

28. Agenda
1. La teoria
2. La tecnologia
3. L'implementazione

29. Integrazione Asp.net - Cardspace
• Activex
– <object> ... </object>
• XHTML behaviour
– <ic:>

30. Asp.net e la login mista
Creo Utente
Aggiorno il profilo
Utente già loggato
con Cardspace
Token Cardspace
postato
User era
loggato?
Associo il profilo
con Cardspace
registrato
con CS?
registrato
con
Usr/Pwd?
Utente non registrato
(nuovo utente)
NoSi
Loggato con
Usr/Pwd?
Aggiorno il profilo
NoSi
No
No
Associare il profilo
solo perché l'email
coincide, è errato
Aggiorno il profilo
Si
Si
L'utente è loggato e
l'associazione ha senso

31. Dare i permessi ad un certificato
1. Aprire una Cmd come administrator
2. c:> FindPrivateKey My localmachine
– FindPrivateKey è negli esempi del Fx 3.0
WCFSamplesTechnologySamplesToolsFindPrivateKeyCS
3. Scegliere il certificato e
copiare la voce "Thumbprint"

32. Dare i permessi ad un certificato
4. Trovare il nome del file per quel certificato:
FindPrivateKey my localmachine –t "thumbprint" -a

33. Dare i permessi ad un certificato
5. Visualizzare i permessi sul file
Cacls nomefile
6. Riassegnare i permessi sul file aggiungendo
network_service
Cacls nomefile /G System:F Administrators:F NetworkService:R
Full Control Full Control Read
7. Verificare i permessi nuovamente (punto 5)

34. Domande?