282 messaggi dal 08 luglio 2008
Ciao a tutti,

premetto che sto passando da .net 4.5 a Core 2.

in passato ho sempre utilizzato le vecchie .net membership provider per progetti web che prevedevano aree riservate.

Mi rendo conto ora che i progetti futuri potrebbero avere bisogno di autenticazione anche su app, mi chiedevo quindi quale deve essere l'approccio per rendere il piu semplice possibile l'autenticazione tra dispositivi diversi (desktop, mobile) e con soluzioni di sviluppo diverse (es .net core per backend, xamarin o app ibride per frontend app)

tralasciando le autenticazioni tramite ips di terze parti (facebook, gmail, ecc.) mi pare di capire che le alternative sono:

1. .net core identity
2. azure directory b2c

Voi cosa mi suggerite? pro e contro delle 2 soluzioni? esistono alternative?

grazie mille
10.903 messaggi dal 09 febbraio 2002
Contributi
Ciao,
c'è una distinzione da fare ma procediamo per gradi.

ASP.NET Core Identity e Azure AD B2C sono due tecnologie di membership. In estrema sintesi, sono in grado di mantenere un database di utenti e di verificare se le loro credenziali all'atto del login sono valide oppure no.
  • Scegli ASP.NET Core Identity per preferisci avere il controllo diretto sul database degli utenti o se da progetto ti è stato detto di riutilizzare i database server che avete già;
  • Scegli Azure AD B2C se vuoi delegare la responsabilità di gestione degli utenti a un servizio cloud, che è certificato per essere compliant con il GDPR e che aggiunge algoritmi di intelligenza artificiale per identificare e ridurre al minimo i tentantivi di furto degli account. Non avrai il controllo diretto sul database ma potrai comunque personalizzare i claim degli utenti e le pagine web legate al profilo.


A login avvenuto, il client riceverà un titolo di autenticazione che tipicamente è un cookie un token in cui sono contenuti i claims dell'utente. Questo titolo viene quindi presentato all'applicazione ASP.NET Core che, verificando che il token sia integro, autenticherà la richiesta. Di questa fase si occupa il middleware di autenticazione di ASP.NET Core, che è un organo separato sia da Identity che da Azure AD B2C. A questo punto devi chiederti: quali scheme di autenticazione voglio supportare in questa applicazione? Cookie? JWT Token? JWT Token via OAuth2? Tutti quanti? Pensa a qual è la modalità più agevole per ogni tipo di client e poi abilita quello scheme. Ad esempio, per un'applicazione ASP.NET Core MVC web potresti scegliere i cookie oppure se è Angular puoi usare JWT Token o Auth2. Fai queste scelte e poi in caso vediamo un po' di codice di come configurare il tutto.

ciao,
Moreno

Enjoy learning and just keep making
282 messaggi dal 08 luglio 2008
Ciao Moreno, grazie per la risposta.

Ma sarebbe possibile usare azure AD b2c solo per la parte di autenticazione utenti di un progetto, ed usare sql server su una propria macchina per il mantenimento di tutti gli altri dati?

Es. in un ecommerce usare azure solo per la registrazione/autenticazione utente, e poi su sql server su una propria macchina mantenere i dati dei prodotti, ordini, ecc...

Quello che vorrei capire è se si possono avere situazioni "ibride" dove non tutto il progetto gira sotto azure...

Mi sto complicando la vita?

Grazie
10.903 messaggi dal 09 febbraio 2002
Contributi
Ciao,

Ma sarebbe possibile usare azure AD b2c solo per la parte di autenticazione utenti di un progetto, ed usare sql server su una propria macchina per il mantenimento di tutti gli altri dati?

Certo, assolutamente sì. Azure AD B2C non vuole sostituirsi all'interno database dell'applicazione, ma solo assolvere alla fase di login/membership.
Quando un utente è loggato, ti troverai in HttpContext.User una ClaimsPrincipal contenente l'identità dell'utente, cioè i suoi claims: username, nome, cognome, email o qualsiasi altro dato avrai abilitato su Azure AD B2C. Ad ogni operazione che lui compie, es. invia un ordine, aggiungi il suo username alla riga che inserisci nel tuo database, così saprai che appartiene a lui.


Quello che vorrei capire è se si possono avere situazioni "ibride" dove non tutto il progetto gira sotto azure...

Sì, è normale avere situazioni ibride. Azure AD B2C è stato costruito proprio per essere interoperabile a prescindere dalla topologia e dal linguaggio. Per esempio potresti allacciarlo ad un'applicazione PHP che gira in un server aziendale, dato che la comunicazione avviene con OpenId Connect. Con ASP.NET Core è molto più facile perché ti basta aggiungere al progetto una riga di configurazione.

ciao,
Moreno

Enjoy learning and just keep making
282 messaggi dal 08 luglio 2008
Ciao BrightSoul,

grazie per le tue risposte sempre molto esaustive.

Ti chiedo se è ancora vero ad oggi che Azure AD B2C non supporta i ruoli. In tal caso ha senso gestire l'autenticazione ad un servizio esterno che però non gestirebbe la parte dei ruoli? Mi sembra un pò un controsenso...soprattutto perchè se non sbaglio il servizio Azure AD invece li gestisce...

Grazie
10.903 messaggi dal 09 febbraio 2002
Contributi
Ciao,
il ruolo puoi semplicemente crearlo come attributo (anche chiamato "claim") nel profilo dell'utente. Dal portale di Azure, nella blade della tua Azure AD B2C puoi cliccare "User attributes" per aggiungere il nuovo attributo. Gli puoi dare il nome che preferisci. "Ruolo" o "Role" può andare.

Poi, vai su "Sign-up or sign-in policies" perché bisogna fare in modo che l'attributo del ruolo venga incluso nel token di autenticazione che Azure AD B2C restituirà alla tua applicazione. Quindi aggiungi policy e da "Application Claims" metti la spunta sull'attributo "Ruolo" che avevi creato prima.

Lato applicazione, autorizzerai o no l'accesso alle tue pagine in base al valore dell'attributo "Ruolo" che ti troverai nella ClaimsIdentity. Come vedi da questo costruttore di ClaimsIdentity, puoi decidere tu come si deve chiamare l'attributo/claim che verrà usato come ruolo.

ciao,
Moreno
Modificato da BrightSoul il 14 giugno 2018 20.37 -

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.