I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio 1 2
flaviovb
flaviovb
il 7 giugno 2019 alle 09:04
427 messaggi dal 13 novembre 2009
Salve,
un confronto. Parte da un esempio. La piattaforma web su cui sto scrivendo prevede piu domini: aspitalia, html5italia ecc..a questi sono legati sottodomini come forum.aspitalia.com ecc. Procedendo alla login i parametri vengono utilizzati per accedere simultaneamente ai vari domini e quindi sottodomini. Pensando ad un sistema del genere o ad uno composto da piu soluzioni, un multitenant, quale la soluzione migliore da adottare. In altri termini partendo da una maschera di login quale sistema adottare per utilizzare la stessa login/token ed in base a quello accedere ai vari domini che compongono la piattaforma ed in base alla licenza acquistata.
Facendo un esempio quindi se la piattaforma è composta da piu domini tutti aspnetcore webapi + client (mvc core angular/blazor) l'intenzione sarebbe quella di creare un sistema di auth che rilasci un token valido per tutte in base alla licenza (quali domini/servizi hai acquistato) e poi sottodomini in funzione del cliente con relative customizzazioni:
dominio1.com, dominio2.com...stesso sistema di auth (middleware)
cliente1.docminio1.com
cliente2.dominio1.com, cliente2.docminio2.com

grazie
RispondiQuoting
BrightSoul
BrightSoul
il 9 giugno 2019 alle 17:15
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


Pensando ad un sistema del genere o ad uno composto da piu soluzioni, un multitenant, quale la soluzione migliore da adottare

Non ho capito se l'applicazione è una sola o se si tratta di più applicazioni diverse.

Se è una sola applicazione, al login puoi rilasciare un token che poi includerai in tutte le successive richieste. Semplicemente, si tratterà solo di cambiare il nome host della richiesta quando l'utente seleziona il tenant da un menu a tendina.

Se invece si tratta di più applicazioni diverse, potresti valutare di implementare il single sign-on usando IdentityServer.

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
flaviovb
flaviovb
il 9 giugno 2019 alle 21:34
427 messaggi dal 13 novembre 2009
allora Innanzitutto il sistema deve essere un servizio con token unico in cui includere su claums una sorta di licenza cioè elenco dei moduli servizi acquistati che corrispondono ai domini sei singoli siti.
Ogni dominio ha una pagina pubblica e verifica lato client il token, se scaduto ad esempio e i claims che prevedono costruzione di un menu ad esempio.
Spero di essere chiaro
RispondiQuoting
BrightSoul
BrightSoul
il 10 giugno 2019 alle 14:12
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


con token unico in cui includere su claums una sorta di licenza cioè elenco dei moduli servizi acquistati che corrispondono ai domini sei singoli siti.

Ok, si può fare. Se all'atto del login emetti un token JWT, poi lato client lo potrai leggere anche da javascript perché il suo payload è sostanzialmente del contenuto JSON in chiaro. In base a quel contenuto potrai generare gli elementi del menu.


Ogni dominio ha una pagina pubblica e verifica lato client il token,

Puoi anche verificare il token lato client se generi la firma usando l'algoritmo RS256, che prevede l'uso di una coppia di chiavi. In pratica, generi la firma con la chiave privata (che non deve MAI essere divulgata lato client) e poi la verifichi lato client con la chiave pubblica. Questo potrebbe esserti d'aiuto.
https://github.com/auth0/node-jsonwebtoken

Comunque... è realmente necessario verificare il token lato client? Se uno smanettone è in grado di alterare il token, sarà anche in grado di bypassare la verifica lato client. È importante che il token venga verificato lato server. A quel punto poco importa se riesce a visualizzare la UI statica di un dominio che non gli compete: tanto i dati non riuscirà a visualizzarli (né a compiere qualsiasi altra operazione dato che la validazione server fallirà).

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
flaviovb
flaviovb
il 10 giugno 2019 alle 16:32
427 messaggi dal 13 novembre 2009
Per verifica lato client del token intendo:
- token scaduto (exp)
- token claims (licenza)
lo smanettone altera il contenuto e lato server il token risulta essere invalido. Il JWT viene verificato lato server. Peraltro il token viene salvato nel database associandolo all'utente che lo ha generato in fase di login. Verifica 1 a 1

l'idea è una homepage per ogni sottodominio e una per il dominio principale. Nelle singole header dei siti ci sarà sempre la sezione login, codice html/blazor (angular) tipo un ascx (direttiva in angularjs) per capirci.
La login richiede alla webapi il token e contiene in claims la licenza, in sostanza i routing di navigazione per intenderci.
Una web mvc con sezioni e masterpage specifiche per sottodominio renderizzano il menu dalle voci claims della licenza tipo:
dominio1/servizio1/attività1
dominio1/servizio1/attività2
dominio2/servizio1/attività1
dominio2/servizio2/attività2
dominio2/servizio2/attività3

se ti fila il problema rimane il multitenant.
RispondiQuoting
BrightSoul
BrightSoul
il 10 giugno 2019 alle 18:55
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


Per verifica lato client del token intendo:
- token scaduto (exp)

Ma perché verificare la scadenza lato client? E se il PC dell'utente ha un orario sballato? Dovresti ottenere la data/ora corrente dal tuo server ma a questo punto tanto vale usare un approccio ottimistico: invii il token nella prossima richiesta così com'è, senza verifiche, e poi catturi gli eventuali errori di validazione restituiti dal server.


Peraltro il token viene salvato nel database associandolo all'utente che lo ha generato in fase di login. Verifica 1 a 1

Ok, considera che questo avrà l'effetto di limitare l'utente a 1 solo login contemporaneo, e ti richiede di interrogare il db a ogni richiesta solo per verificare che il token corrisponda.


se ti fila il problema rimane il multitenant.

Puoi mettere il tenant nei claim. I domini già li inserisci, perciò il client avrà tutto quello che gli serve per far navigare l'utente sui siti a lui destinati.

ciao,
Moreno
Modificato da BrightSoul il 10 giugno 2019 18:59 -
Modificato da BrightSoul il 10 giugno 2019 19:34 -
Enjoy learning and just keep making
RispondiQuoting
flaviovb
flaviovb
il 10 giugno 2019 alle 20:16
427 messaggi dal 13 novembre 2009
Ineccepibile!
Il salvataggio del token è legato al fatto che vorrei limitare uso utente ad un solo accesso contemporaneo. Mario e Luca non possono usare lo stesso user password. Chi si legga con quellutente per ultimo, vince
RispondiQuoting
flaviovb
flaviovb
l'11 giugno 2019 alle 10:30
427 messaggi dal 13 novembre 2009
Domanda! A questo punto perché utilizzare la proprietà tenant. Mi spiego, se un utente si logga viene riconosciuto come utente appartenente ad una organizzazione ed in base ad un contratto con una serie di accessi, la licenza, con routing corrispondenti a sottodominio/servizio/attività. A quel punto quale logica applicare al tenant?
RispondiQuoting
1 2

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.