Single Sign On con IdentityServer
Download as PPTX, PDF0 likes553 views
Il documento tratta l'autenticazione e l'autorizzazione nel contesto della federazione dei profili utente, con un focus sull'uso dei 'claim' e dei 'security token'. Viene discusso il ruolo degli STS (Security Token Service) e dell'ACS (Access Control Service) nel gestire tali processi, mettendo in evidenza le problematiche legate alla gestione sicura delle credenziali e della privacy. Si sottolinea infine che OAuth 2.0 è un protocollo di autorizzazione delegata, non di autenticazione.
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
- 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/