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

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

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 -