Ho un'applicazione in cui gli utenti possono accedere con vari livelli di permessi. Dal loro cliente inviano un nome utente & password per il front-end, che passa al back-end, e da lì abbiamo alcune chiamate diverse.
Supponendo che le cose vadano bene in ogni fase:
- Controlla un nome utente & password con il nostro servizio di autenticazione di identità.
- Cerca nel nostro database locale le preferenze dell'utente relative all'app.
- Invia nome utente al servizio di autorizzazione A, torna ID_A.
- Invia ID_A al servizio di autorizzazione B, torna ID_B.
- Invia ID_B al servizio di autorizzazione B, recupera le autorizzazioni degli utenti relative all'app.
Finalmente impaccheremo le preferenze e le autorizzazioni in un token, firmeremo e passeremo indietro al client.
Alcune note per il contesto:
- ID_A non cambia.
- ID_B può o non può esistere se l'utente ha pochissime autorizzazioni; se non recuperiamo un ID_B, va bene, non hanno quasi nessun accesso.
- Se ID_B esiste, cambierà molto raramente, in un intervallo di tempo di mesi o anni, se non del tutto.
- Anche le autorizzazioni utente dal servizio B cambiano raramente, ma è importante per la logica aziendale verificare tali autorizzazioni ad ogni accesso.
- Servizi di autorizzazione A & B sono entrambi venditori di terze parti. Improbabile che cambi in qualunque momento presto, ma mai dire mai.
Opzione 1
Le tre chiamate che sto facendo ai servizi di autorizzazione sembrano molte, quindi penso che potrei fare un corto circuito salvando ID_A o ID_B nel database dell'applicazione.
- Poiché ID_A non cambia, posso salvare me stesso la chiamata n. 3 ogni volta se la prendo dal DB locale durante la chiamata n. 2.
- Poiché ID_B cambia così raramente, potrei anche tenerlo nel DB locale per salvare la chiamata # 4.
- Se dovessi ottenere una risposta negativa dalla chiamata n. 5 con ID_B nel mio database, potrei provare a chiamare # 4 e vedere se l'ID_B è stato aggiornato.
Opzione 2
Un'altra opzione che ho più o meno escluso è l'archiviazione di ID_A / ID_B nel mio servizio di autenticazione di identità. Posso aggiungere alcuni attributi utente e recuperarli con il controllo iniziale alla chiamata n. 1, ma se aggiungiamo altre applicazioni in futuro che fanno uso dello stesso servizio di autenticazione di identità e potremmo utilizzare il servizio di autorizzazione A, B o C & D, penso che stia cominciando a essere un disastro nel servizio di identità.
Domanda
Renderebbe logico o valido l'architettura archiviare gli ID dei servizi A e B nel database delle applicazioni? Certamente funzionerebbe, ma questa è una pessima decisione di progettazione? Devo fare quelle chiamate ogni volta? O c'è un altro posto che dovrei salvare / mettere in cache quegli ID?