Ho un'applicazione web multi-tenant che si autentica contro Azure Active Directory e consente agli utenti di modificare il contenuto. Qual è il modo appropriato per me per visualizzare il nome dell'ultima persona che ha modificato un'entità?
Ad esempio, quando pongo questa domanda, avrà il mio ID utente legato ad esso. Tuttavia, quando lo leggi, non vedi che l'utente 124633 ha pubblicato una domanda, vedi Matthew Haugen. Questo può essere fatto attraverso una vista SQL, o un oggetto di ritorno complesso, o una seconda chiamata API, o un numero qualsiasi di mezzi intelligenti.
Questo è abbastanza diretto per tutto ciò che utilizza l'autenticazione personalizzata (come tramite ASP Identity, o qualsiasi altra cosa), ma quando l'autenticazione è interamente controllata da un singolo servizio di terze parti, c'è un po 'di disconnessione.
Per come la vedo io, anche se potrei sbagliarmi, ho due opzioni di base:
- Chiama l'API Graph per ottenere informazioni sull'utente ogni volta che un utente visualizza il contenuto.
- Memorizza il nome di ogni persona che si autentica contro la mia API (o sito).
Il primo ha alcuni pro, è leggero, non sono responsabile se l'organizzazione ha qualche strana politica che una persona non può vedere il nome di un altro, e qualsiasi aggiornamento AD (come qualcuno che cambia nome ) si riflettono immediatamente.
Ma allo stesso tempo, non sono sicuro (anche se forse qualcuno può chiarirlo) come questo reagirebbe ai dipendenti che sono stati licenziati o che altrimenti lasceranno l'organizzazione. Soprattutto se qualcuno viene licenziato, sarebbe bello sapere che sono quelli che hanno modificato il contenuto, piuttosto che averlo elencato un GUID casuale usato per riferirsi ad essi.
Fondamentalmente, preferirei usare semplicemente l'API Graph, a parte il fatto che sono preoccupato per i dipendenti i cui account AD sono disabilitati. Ma sono aperto a suggerimenti anche oltre.
Non sono riuscito a trovare nulla tramite la ricerca (questa è una cosa difficile da cercare), ma la comoda barra delle domande simili mi ha dato i seguenti due post:
- Il miglior approccio per la gestione degli utenti che sono definiti all'interno della directory attiva, all'interno della mia applicazione personalizzata : questo sembra che l'utente stia chiedendo qualcosa di molto simile a me, ma sembra che siano preoccupati per i dati personalizzati oltre ai soli campi del nome, e Non lo sono.
- link : Non sono completamente chiaro sulla domanda qui, ma sembra che stiano cercando, ancora una volta, per la memorizzazione di informazioni ausiliarie o che consentano ai loro dati di sincronizzarsi con Active Directory, che non è qualcosa di cui avrò mai bisogno (se hanno bisogno di cambiare qualcosa, possono farlo direttamente nel loro annuncio - nel peggiore dei casi, imposterò l'API Graph per proxy tali modifiche attraverso l'interfaccia utente).
Per essere chiari, I non deve:
- Memorizza informazioni utente extra.
- Sollecita le prestazioni di questa singola funzione.
- Consenti a chiunque al di fuori dell'organizzazione dell'utente di leggere il suo nome.