5 messaggi dal 26 dicembre 2010
Grazie per la risposta.
L'applicazione è ancora in 4.5.1 però ho visto che i relative package nuget per JWT sono disponibili anche per quella versione.

Il db è locale all'applicazione e gli utenti sono gestiti da amministrazione.

Gli utenti si loggano con account di dominio e dal db l'applicazione carica i permessi per poter navigare nella parte client. Parallelamente, con Basic Authentication vengono consumate delle API CORS da applicazioni esterne.

Quello che manca è lo strato di Authorize per impedire di chiamare API se non hai ricevuto uno specifico permesso.
Modificato da e73779 il 22 giugno 2018 09.50 -
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao, dato che hai già in piedi la basic authentication ti conviene sfruttare quella.
Presumo tu abbia un delegating handler tipo questo per verificare le credenziali che ti vengono passate. In quel punto, estrai dal database anche i ruoli dell'utente e li inserisci nel claim Role della sua ClaimsIdentity come vedi qui.
Poi, sulle action di ASP.NET Web API poni l'attributo [Authorize(Roles = "Role1")] per autorizzare solo gli utenti che possiedono un certo ruolo.

Se vuoi, puoi aggiungere un ulteriore delegating handler che emetta dei TokenJWT. Questo avrà un vantaggio: dato che il token contiene i claims dell'utente, ti eviterà di dover fare query al database ad ogni richiesta come stai facendo ora con la basic authentication. Inoltre, permette all'utente di non dover fornire la password ad ogni richiesta ma ti fornirà il token JWT. Ecco un'applicazione di esempio che combina basic authentication e token JWT.
https://github.com/BrightSoul/DemoLoginWebAPI
Nel readme trovi un diagramma che spiega il funzionamento.

ciao,
Moreno
Modificato da BrightSoul il 22 giugno 2018 13.58 -

Enjoy learning and just keep making
5 messaggi dal 26 dicembre 2010
Grazie mille, Moreno!!
Buon We,
Fabio
2 messaggi dal 24 maggio 2018
Ciao, ho utilizzato la tua guida per creare i token degli utenti.
Nei controller ora ho dei metodi protetti da [Authorize] che possono essere chiamati solo da chi ha un token valido.
Mi chiedo: come posso sapere l'identità di chi ha chiamato quel metodo?

Per esempio io vorrei legare il token a uno User con nome, cognome, ruolo, città. Come posso fare?
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,
per aggiungere nome, cognome, ruolo e città al token, ti basta usare il metodo AddClaim della ClaimsIdentity, come mostrato in questo script nel TokenController.
  • Per indicare lo username, usa ClaimTypes.Name
  • Per il ruolo, usa ClaimTypes.Role
  • Per il nome di battesimo, puoi usare ClaimTypes.GivenName (ma puoi anche scegliere tu una stringa arbitraria come nome del claim)
  • Per il cognome, puoi usare ClaimTypes.Surname (o stringa arbitraria)
  • Per la città, puoi usare ClaimTypes.Locality (o stringa arbitraria)


Poi, per recuperare questi valori dall'action di un controller, fai così:
//Qui uso ClaimTypes.Role ma tu scegli il claim che ti interessa recuperare
//Es. ClaimTypes.Name per lo username
string ruolo = (User as ClaimsPrincipal)?.FindFirst(ClaimTypes.Role)?.Value;

Se l'utente non dovesse essere autenticato o se il claim "Role" non dovesse essere stato aggiunto, la variabile "ruolo" sarà null. Altrimenti, se la variabile "ruolo" contiene un determinato valore, puoi compiere delle operazioni.
if (ruolo == "Adminitrator") {
  //Compi operazione riservata all'amministratore
} else {
  //restituisci status code 403 Forbidden
}

Questa è logica di autorizzazione starebbe meglio segregata in un attributo, dato che ti capiterà di riutilizzarla parecchie volte per proteggere le tue action. L'attributo Authorize, come vedi qui, infatti, ti consente di autorizzare determinati ruoli e utenti, quindi la logica che ti ho mostrato qui sopra diventa inutile perché ti basta fare:
[Authorize(Roles = "Administrator")]
public ActionResult MiaAction() {
}

Oppure, per autorizzare determinati utenti in base al loro username
[Authorize(Users = "User1,User2")]
public ActionResult MiaAction() {
}


Se vuoi autorizzare l'utente in base ad altri claim, tipo la città, allora l'attributo Authorize non ti consente di farlo ma potrai scriverne uno tuo personalizzato da usare così:
[AuthorizeByClaim(ClaimTypes.Locality, "Roma")]
public ActionResult MiaAction() {
}


ciao,
Moreno
Modificato da BrightSoul il 23 giugno 2018 10.32 -

Enjoy learning and just keep making
710 messaggi dal 13 novembre 2008
Contributi
ciao, ho un progetto che deve essere il più possibile 'disaccoppiato' e che prevede diversi tipi di client autorizzati da un unico endpoint, quindi ritengo JWT un ottima soluzione; ho impostato seguendo questo articolo l'Api web che fornisce il token, poi un'Api web che fornisce dei dati da uno storage se riceve il token. Facendo delle chiamate con Postman, prima per il token, poi all'Api dati con l'header bearer il tutto funziona. I client del progetto che dovranno essere autorizzati sono al momento una SPA con Angular, una con html e jquery e una webapp con MCV; per le SPA non vedo problemi, faccio delle chiamate per il token passando user e password, poi inserisco il token nell'header per prelevare i dati dall'altra API; mi interessa però il discorso su MVC e su come poter prelevare e usare il token per fornire l'autorizzazione per tutta la WebApp, è possibile approfondire con un esempio?
Mi piacerebbe avere anche qualche dritta per la verifica della scadenza del token prima di emetterne un'altro....
Per ultimo secondo te è consigliabile implementare anche una SPA a se stante per l'operazione di login?
Grazie e ottimo articolo!
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao e grazie,

mi interessa però il discorso su MVC e su come poter prelevare e usare il token per fornire l'autorizzazione per tutta la WebApp

Quando l'utente fa il login sulla Webapp emetti un cookie di autenticazione. Se usi ASP.NET Identity, il cookie di autenticazione contiene i claim della ClaimsIdentity che rappresenta l'utente. Puoi aggiungere un ulteriore claim il cui valore sarà il token JWT. In questo modo, in tutte le successive richieste dell'utente, potrai estrarre il token dal cookie e usarlo per invocare la web api.



Mi piacerebbe avere anche qualche dritta per la verifica della scadenza del token prima di emetterne un'altro....

Qui puoi fare a tua discrezione: ad esempio puoi emettere token short-lived (es. 10 minuti) e rigenerarne uno nuovo ad ogni richiesta. Ne consegue che se un utente non invia richieste per 10 minuti dovrà fornire di nuovo le credenziali. Questo potrebbe essere un vantaggio se vuoi imporre il reinserimento delle credenziali dopo un periodo di inattività ma potrebbe anche essere uno svantaggio se hai requisiti di sicurezza un po' più rilassati.
Puoi anche emettere un token che è valido per 1 mese e rinnovarlo automaticamente quando mancano 10 giorni alla scadenza, però poi ti devi dare un meccanismo per invalidare il token prima della scadenza. Supponiamo che un impiegato perda il ruolo di amministratore: non deve poter continuare ad usare il suo token valido per 1 mese. Quindi ci puoi mettere all'interno, come claim, un codice di sicurezza e verificare periodicamente se corrisponde a quello contenuto nel database. Quando cambi il ruolo di un utente, rigenera il codice di sicurezza situato nel database. La prossima volta che l'utente ti presenterà un token, lo rifiuti perché contiene un codice di sicurezza diverso. Puoi fare questo controllo ogni tot tempo, per evitare una query al database ad ogni invocazione che la tua api riceve. Se vuoi fare questa validazione manuale, puoi leggere qui.


Per ultimo secondo te è consigliabile implementare anche una SPA a se stante per l'operazione di login?

Dipende dal tuo scenario. Se vuoi creare un server centralizzato per il single sign-on puoi farlo. Leggi questo articolo, è un po' datato ma serve a spiegare il concetto.
http://www.aspitalia.com/articoli/asp.net/single-sign-on-identity-server.aspx

ciao,
Moreno

Enjoy learning and just keep making
710 messaggi dal 13 novembre 2008
Contributi
Quando l'utente fa il login sulla Webapp emetti un cookie di autenticazione. Se usi ASP.NET Identity, il cookie di autenticazione contiene i claim della ClaimsIdentity che rappresenta l'utente. Puoi aggiungere un ulteriore claim il cui valore sarà il token JWT. In questo modo, in tutte le successive richieste dell'utente, potrai estrarre il token dal cookie e usarlo per invocare la web api.

si ok, ma io vorrei che l'utente non facesse il login sulla webapp Mvc , che per me è un client come un altro, vorrei farlo entrare sulla SPA di login e renderlo autenticato in Mvc come negli altri client, passandogli il token, ma ho dei dubbi se si possa fare....

vorrei capire se il tutto è fattibile senza andare ad usare Identity Server

ciao
Modificato da teo prome il 26 settembre 2018 15.03 -

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.