Successfully reported this slideshow.
Your SlideShare is downloading. ×

Implementare il single sign on con IdentityServer

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Introduzione a CardSpace
Introduzione a CardSpace
Loading in …3
×

Check these out next

1 of 32 Ad

More Related Content

Similar to Implementare il single sign on con IdentityServer (20)

More from Mauro Servienti (20)

Advertisement

Recently uploaded (20)

Implementare il single sign on con IdentityServer

  1. 1. 18 Novembre 2016 Single Sign On con Identity Server Mauro Servienti
  2. 2. A volte ritornano ho fatto una sessione simile la prima volta a Windows Developer Conference nel 2012
  3. 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. 4. Coming out ho un biglietto per i Depeche e ho appena visto i Cure
  5. 5. Sicurezza, ovunque sicurezza. Torniamo seri che la sicurezza è importante
  6. 6. …e Trenitalia non sa cosa sia. Password in chiaro, case insentive. #ciaone
  7. 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. 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. 9. Profiles Claims Come funziona di solito Applicazione Backend/FBA Users
  10. 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. 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. 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. 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. 14. la federazione It’s a long way to the top if you wanna rock ‘n’ roll…
  15. 15. La federazione App Backend/FBA Trusted 3rd party STS Nonèunproblemanostro Profiles Claims Users nameidentifier nameidentifier
  16. 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. 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. 18. Applicazione Autorizzazione Applicazione Autenticazione e richiesta di accesso Generazione del Token Accesso all’API con il Token
  19. 19. La federazione App Backend/FBA Trusted 3rd party STS Nonèunproblemanostro Profiles Claims Users nameidentifier nameidentifier
  20. 20. Uno solo!?111?1?!!! Gomblotto :-)
  21. 21. Abbiamo abituato bene i nostri utenti…
  22. 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. 23. FacebookGoogle Account La federazione App Backend Custom FBA Profiles IdentityServer ACS Active Directory MS Account nameidentifier Nonèunproblemanostro Twitter
  24. 24. FacebookGoogle Account Ad ognuno il suo protocollo Custom FBA IdentityServer ACS Active Directory MS Account Twitter
  25. 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. 26. Ma non è così semplice
  27. 27. Lei e lui • Gli attori sono due • Utente • ApplicazioneUtente Applicazione STS/ACS
  28. 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. 29. OAuth Una piccola nota di redazione…
  30. 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. 31. Demo
  32. 32. Grazie Mauro Servienti Solution Architect @ Particular Software | @mauroservienti | //blogs.ugidotnet.org/topics/

×