Aggiornamento al tuo aggiornamento.
So I am looking at building something into my web page that allows the business user to pick an end user from a list of names, then pass that login name along to the web server and have the web server render a page with the info the end user should see.
Il problema qui è che il tuo back-end è attualmente impostato per acquisire un'identità Windows. Le identità di Windows per un'app di IIS non dovrebbero essere configurabili dal lato del client , in quanto ciò garantisce una backdoor ovvia per i client dannosi.
Ci sono molti modi per affrontarlo senza compromettere l'attuale configurazione di autenticazione del backend:
- Sul computer client, si esegue il browser con l'account dell'utente desiderato.
- Vai al browser .exe
- Maiusc + fai clic con il pulsante destro del mouse
- Seleziona "Esegui come utente diverso" e accedi con le sue credenziali (questo ovviamente richiede conoscere la loro password).
- Questo browser dovrebbe inviare correttamente le credenziali dell'utente selezionato al server di back-end.
- Nella configurazione IIS back-end, è possibile impostare il pool di app per impersonare un utente. Tieni presente che ciò influisce su tutte richieste. Questo è un approccio facile se sei, ad es. eseguire il debug localmente, ma ovviamente non dovresti mai farlo in produzione (o in qualsiasi ambiente con più utenti simultanei).
- Puoi trovarlo nelle impostazioni avanzate del pool di app.
- Ciò richiede anche conoscere la password dell'utente.
La necessità della password dell'utente è una funzione ricorrente qui, per una buona ragione . Nessuno tranne l'utente è autorizzato a compiere azioni per conto dell'utente. Anche quelli con più diritti rispetto all'utente non possono ancora fingere di essere l'utente (almeno nella sicurezza interna di Windows).
Tuttavia, sono ancora sul punto di stabilire se l'impersonazione dell'utente sia un buon approccio. Sembra un approccio troppo zelante. Se c'è qualche auditing sull'applicazione (che mi aspetterei da un'applicazione del libro paga), allora uno sviluppatore è effettivamente in grado di nascondere le sue azioni.
Cosa impedisce a uno sviluppatore di fingere di essere qualcun altro e possibilmente di aggiornare i dati del libro paga? Se possono scegliere di essere chiunque siano, allora stai dando loro le chiavi del castello.
Un approccio migliore sarebbe mantenere l'identità effettiva dell'utente, ma prendere in giro le loro impostazioni . In questo modo, si ottiene sempre lo stesso output deriso, senza compromettere la sicurezza dell'audit. Lei parla di diversi dipartimenti, quindi presumo che questa sia l'impostazione che si vuole prendere in giro.
- Dai ai tuoi sviluppatori un privilegio speciale in AD o assegnali a un gruppo speciale (ad esempio CAN_MOCK_DEPARTMENT)
- Il backend esegue un ulteriore elenco a discesa "seleziona il tuo reparto" sulla pagina web se l'utente corrente fa parte del gruppo / privilegio CAN_MOCK_DEPARTMENT.
- Quando un tale sviluppatore invia una richiesta al back-end, invece di prendere il dipartimento dell'utente corrente; il backend utilizzerà il valore del menu a discesa "seleziona il tuo reparto". Per tutti gli altri utenti, il back-end userà sempre il loro reparto attuale.
- Assicurati che il backend non si basi sul dropdown del dipartimento per gli utenti non sviluppatori! Un utente intelligente può modificare il valore di questo menu a discesa anche se è disabilitato (tramite jQuery nella console F12)!
La risposta originale.
I have a need for a group of tech users to be able to impersonate business users so that the tech users can see the same page the business user sees and confirm that the app is correctly configured for the business user.
Questo genera una bandiera rossa enorme per me.
Esiste una differenza molto significativa tra la rappresentazione di un'identità autenticata e la capacità di rispecchiare i privilegi o le impostazioni di un utente.
We are talking about seeing payroll data for different departments.
I tuoi sviluppatori dovrebbero avere diritti espliciti per prendere in giro il dipartimento a cui appartengono, nell'apposita cartella (non a livello di AD). Questo non è affatto simile alla rappresentazione di un account utente attraverso la rete.
Pensa a cosa stai chiedendo. Stai chiedendo la possibilità di fingere di essere qualsiasi utente, a volontà, senza il permesso logicamente dimostrabile da parte di detto utente, in ogni momento, che ti darà accesso a informazioni altamente riservate sui libri paga.
Se hai la password dell'utente, farlo è banale (basta accedere come loro). Se non hai la loro password, ma in qualche modo sei stato in grado di fingere di essere loro comunque, allora qual è il punto di avere una password?
Stai effettivamente chiedendo "come faccio a bloccare a chiave tutte le porte anteriori perché a volte vorrei testare i televisori di alcuni dei miei vicini".
La risposta diretta qui è che devi avere una simile TV (proprio come hai un privilegio / dipartimento simile), oppure lo fai semplicemente con l'espressa autorizzazione del proprietario (ad esempio facendoti accedere al loro account o prendendo il controllo remoto del loro computer).
Se tu fossi in grado di fare ciò che ti aspetti di poter fare; quindi la sicurezza non ha senso.