Single Sign On con IdentityServer

1. 18 Novembre 2016
Single Sign On con Identity Server
Mauro Servienti

2. A volte ritornano
ho fatto una sessione simile
la prima volta a
Windows Developer Conference
nel 2012

3. Mauro Servienti
appassionato di cibo e sport
lo sport è in funzione del cibo
la tecnologia mi annoia
Dicono di me: era un bravo programmatore (cit. Ema)
pretend to be an architect

4. Coming out
ho un biglietto per i Depeche
e ho appena visto i Cure

5. Sicurezza, ovunque sicurezza.
Torniamo seri che la sicurezza è importante

6. …e Trenitalia non sa cosa sia.
Password in chiaro, case insentive. #ciaone

7. Autenticazione e Autorizzazione
• Autenticazione: verifica che siate chi dite di essere
• Ad esempio tramite una combinazione di Username e Password
• Autorizzazione: verifica che possiate fare quello che cercate di fare
• Ad esempio tramite ruoli e claim

8. «claim» questi sconosciuti
• Abbiamo sempre pensato in termini di Gruppi/ACL
• .NET ha introdotto nel 2001 i «ruoli»
• Mai decisione fu più nefasta :-)
• Finalmente i «claim» cercano di mettere ordine nel caos
• È semplicemente un attributo dell’utente
• Il nome, lo user-id, la mail, i ruoli, l’età possono essere tutti «claim»
• È compito, come è ovvio che sia, del client decidere come
interpretarlo

9. Profiles
Claims
Come funziona di solito
Applicazione Backend/FBA
Users

10. È veramente un problema nostro?
• Date le seguenti «robe»:
• Utenti
• Claim
• Profili
• Ce ne dobbiamo occupare noi?
• No, o meglio non proprio:
• Utenti: no
• Claim: probabilmente in parte
• Profili: si

11. Perché gli utenti no
• smazzarsi la gestione sicura di username e password è noioso
• Quanti di voi fanno hashing con salt random delle password?
• Quanti di voi hanno il supporto per 2FA?
• Quanti di voi hanno SSL EV?
• Quanti di voi hanno 2FA per il cambio password?
• gli utenti odiano creare un altro utente per usare un servizio
• la privacy è una rottura che non volete gestire

12. Perché i claim in parte si
• Molti claim comuni a tanti utenti a prescindere
• altri no sono peculiari
• Non è quindi detto che quello che ci troviamo a disposizione basti

13. Perché i profili si
• Il profilo è un problema totalmente applicativo
• Un «utente», inteso come user, rappresenta l’utente in generale
• Un profilo rappresenta un utente nel contesto applicativo

14. la federazione
It’s a long way to the top if you wanna rock ‘n’ roll…

15. La federazione
App Backend/FBA
Trusted
3rd party
STS
Nonèunproblemanostro
Profiles
Claims
Users
nameidentifier
nameidentifier

16. STS (security token service)
• Non è un problema nostro: ci limitiamo alla fiducia
• Il suo unico ruolo è emettere Security Token
• Tipicamente dopo aver verificato le credenziali, qualsiasi esse siano
• Un Security Token:
• È crittografato e firmato
• La fiducia di cui sopra dice che lo possiamo spacchettare
• Contiene tutte le informazioni relative all’utente

17. Il flusso federato
• L’utente si presenta e non è autenticato
• L’applicazione lo rimbalza verso l’STS
• Dandogli un token che identifica l’applicazione
• Token che solo l’STS può spacchettare
• L’utente si presenta all’STS con il token
• L’STS a questo punto sa da dove arriva l’utente
• L’utente si autentica con le sue credenziali
• L’STS genera un security token valido e con una scadenza
• L’utente torna dall’applicazione
• L’applicazione spacchetta il security token e sa che l’utente è buono

18. Applicazione Autorizzazione Applicazione
Autenticazione e
richiesta di accesso
Generazione
del Token
Accesso all’API con il Token

19. La federazione
App Backend/FBA
Trusted
3rd party
STS
Nonèunproblemanostro
Profiles
Claims
Users
nameidentifier
nameidentifier

20. Uno solo!?111?1?!!!
Gomblotto :-)

21. Abbiamo abituato bene i nostri utenti…

22. Un STS non ci basta più
• Abbiamo bisogno di un ACS
• Access Control Service
• Fa da proxy verso uno o più STS
• Noi ci fidiamo dell’ACS, lui si fida degli STS
• E per proprietà transitiva siamo tutti felici
• Possiamo fare self-hosting dell’ACS
• APS.Net 4 lo faceva
• Possiamo delegare a terze parti come l’IdentityServer di Thinktecture
• Di cui a sua volta si può fare self-hosting

23. FacebookGoogle Account
La federazione
App Backend
Custom FBA
Profiles
IdentityServer
ACS
Active Directory MS Account
nameidentifier
Nonèunproblemanostro
Twitter

24. FacebookGoogle Account
Ad ognuno il suo protocollo
Custom FBA
IdentityServer
ACS
Active Directory MS Account Twitter

25. Applicazione Autorizzazione Applicazione
Autenticazione e
richiesta di accesso
Generazione
del Token
Accesso all’API con il Token
Azure ACS
Autenticazione
Consenso
Codice di Accesso
Codice di Accesso

26. Ma non è così semplice

27. Lei e lui
• Gli attori sono due
• Utente
• ApplicazioneUtente Applicazione
STS/ACS

28. Lei, lui e l’altra
• Gli attori sono tre
• Utente
• Applicazione
• API
• L’utente vuole accedere all’API
• Attraverso l’applicazione
• Una SPA deve funzionare così
• Tipicamente si parla di OAuth
Utente Applicazione
STS/ACS
API

29. OAuth
Una piccola nota di redazione…

30. The problem is that OAuth 2.0 is a
Delegated Authorization protocol, and not
a Authentication protocol. ...
OAuth provides an access token to a client, so
that it can access a protected resource, based on
the permission of the resource owner.
Fonte: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

31. Demo

32. Grazie
Mauro Servienti
Solution Architect @ Particular Software | @mauroservienti | //blogs.ugidotnet.org/topics/