Requisiti di sicurezza dichiarativi: SecurityAction.Demand è memorizzato nella cache?
-
03-07-2019 - |
Domanda
Sto riscontrando problemi durante la rappresentazione di un utente. Ho un metodo dichiarato in questo modo:
[PrincipalPermission(SecurityAction.Demand, Name=@"DJPITER-PC\Test", Role="LocalTestGroup")]
static void LocalTestGroupOnly()
{
Console.WriteLine("Inside LocalTestGroupOnly() - {0}",
WindowsIdentity.GetCurrent().Name);
}
Il codice chiamante è:
WindowsImpersonationContext context =
WindowsIdentity.Impersonate(token);
Console.WriteLine("Calling LocalTestGroupOnly() as {0}",
WindowsIdentity.GetCurrent().Name);
LocalTestGroupOnly();
context.Undo();
try
{
// Reverted user is displayed properly
Console.WriteLine("Calling LocalTestGroupOnly() as {0}",
WindowsIdentity.GetCurrent().Name);
// This method should fail but if succeeds
LocalTestGroupOnly();
}
catch (SecurityException ex)
{
Console.WriteLine("Your account lacks permission to that function.");
}
L'utente predefinito NON è membro di LocalTestGroup. Utente indicato dal token membro IS di LocalTestGroup.
Il problema:
La prima chiamata a LocalTestGroupOnly () ha esito positivo perché l'utente indicato dal membro IS token di LocalTestGroup. La seconda chiamata (come utente predefinito) a LocalTestGroupOnly () non dovrebbe riuscire perché l'utente predefinito non è "Test" e non appartiene a LocalTestGroup. Il problema è che anche questo metodo ha esito positivo.
Se eseguo il programma separatamente - con e senza imitazione il comportamento che correggiamo: ha successo quando si impersona come 'Test' e fallisce quando si chiama come utente predefinito.
Qual è il problema qui?
Soluzione
Potresti controllare Thread.CurrentPrincipal.Identity
invece di WindowsIdentity.GetCurrent ()
? PrincipalPermission.Demand ()
utilizza il primo.
Per cambiare Thread.CurrentPrincipal
(o HttpContext.User
) sembra che tu debba impostarli esplicitamente dopo la rappresentazione o dopo un annullamento. Controlla qui per una domanda simile .