Quale approccio utilizzare quando l'amministratore può agire come un utente nell'applicazione?

Question

Quale approccio utilizzare quando l'amministratore può agire come un utente nell'applicazione?

#1 da (2 voti)
#2 da (1 voti)

1

L'applicazione richiede che l'utente amministratore possa fornire le stesse azioni come l'utente reale. È una situazione normale quando nell'applicazione cambia IIdentity in modo tale che quando facciamo clic sul pulsante "Accedi come un utente" il risultato è come se questo utente effettuasse l'accesso tramite la pagina di accesso predefinita, ma in questo IIdentity abbiamo proprietà IsAdminLoginLikeSomeUser che mostra che è il login dell'amministratore come un utente?

Ho un secondo approccio quando l'utente che è autorizzato in questa situazione Admin, quando si fa clic sul pulsante "Accedi come un utente" l'utente amministratore rimane autorizzato, ma a IIdentity aggiungerà la proprietà AndminActAsUserId , che consente all'amministratore di comportarsi come un utente.

L'applicazione richiede che l'amministratore possa aiutare alcuni utenti agendo come un utente.

La mia domanda: Quale approccio salva la sicurezza? Lo chiedo perché sento che il primo approccio non è molto buono e sarà molto insicuro.

Spero che qualcuno abbia un'esperienza e possa aiutarmi a risolvere questo problema.

c# asp.net-mvc identity

posta Stanislav Machel 07.11.2017 - 07:55

fonte

2 risposte

Leggi altre domande sui tag c# asp.net-mvc identity

Soluzione per l'ingombro del codice in crescita Come posso ottenere un programma progettato per funzionare continuamente (conversione di dati su una porta COM seriale) per uscire?

score 2 · Answer 1

Sicurezza

Da un punto di vista sicurezza , le migliori pratiche relative alla prevenzione degli utenti che in qualche modo recuperano informazioni sensibili nella memoria del server sono sempre applicabili. Ciò include la visualizzazione di un elenco di tutti gli utenti che impersonano prima l'utente in questione è stato autenticato. Altrimenti, non esiste un approccio migliore qui.

Architettura

Da un punto di vista dell'architettura, è logico che tu continui a utilizzare IIdentity per tutto il tuo programma come prima senza dover controllare una proprietà "IsAdminLoginLikeSomeUser", quindi dovresti concentrarti su questo in quanto richiede la minima quantità di cambiamento da eseguire sulla tua applicazione web.

Attuazione

In ultima analisi, le modifiche equivalgono a convalidare le credenziali dell'utente come faresti sempre. Un utente normale è autenticato così com'è e un amministratore è autenticato così com'è. La differenza sta nel fatto che in aggiunta a le normali credenziali, un amministratore può anche accedere come utente diverso. Dato che non vorresti che tutti gli utenti vedessero l'elenco degli utenti esistenti, questa dovrebbe essere un'operazione di post-signin (l'amministratore è già autenticato).

Uso

Nel momento in cui l'amministratore sceglie di accedere come un altro utente, dovresti trattarlo come secondo accesso. La classe che implementa IIdentity deve essere sostituita con un'altra per questo caso speciale che non fa altro che incapsulare l'utente amministratore e l'utente da imitare. Per tutto ciò che riguarda le autorizzazioni, si restituiscono i risultati dell'utente da imitare. Se viene richiesto il nome o i dati utente, è possibile restituire i risultati all'utente amministratore. Non dimenticare di aggiornare la pagina lato client in seguito per alterare potenzialmente la pagina per mostrare ciò che l'utente vedrebbe con le sue autorizzazioni!

Non dovrebbe essere necessario sapere se l'utente corrente è amministratore che finge di essere un altro utente in tutto il programma e, in sostanza, questo aspetto è trasparente per il resto del programma se eseguito correttamente.

score 1 · Answer 2

Da un punto di vista della sicurezza e senza altre misure tecniche, nessuno di questo approccio è buono. Entrambi:

non attuare la separazione dei compiti,
consente all'amministratore di eseguire azioni che non è autorizzato a fare
consente all'amministratore di impersonare un utente
non è in grado di fornire una verifica attendibile su chi ha fatto cosa
fornisce un'autostrada per gli hacker che abusano del sistema se riescono a ottenere la password dell'amministratore.

Se questo è per una missione critica o per un sistema finanziario, questo sarebbe inaccettabile.

Tuttavia, con un indirizzo di codice aggiuntivo è possibile affrontare questi diversi problemi, ad esempio estendendo la registrazione e il percorso di controllo in modo che le azioni per conto siano sistematicamente identificate e informando l'utente delle azioni intraprese per suo conto.

Eventualmente potresti anche aggiungere un pulsante di richiesta di supporto per l'utente, in modo che l'amministratore possa intervenire solo per i pochi utenti che hanno attivato un indicatore di richiesta.

Il secondo approccio sembra più promettente in questo senso. Capisco che in questo scenario, l'amministratore è considerato come se stesso e che l'agire per conto funzionerà solo se il codice di controllo dell'autorizzazione è in grado di far fronte al caso d'uso per conto, mentre il primo approccio sarebbe immediatamente una porta aperta, anche per le funzioni che non erano ancora state aggiornate con la logica di sicurezza aggiuntiva.