Demandas de seguridad declarativas: ¿se almacena en caché SecurityAction.Demand?
-
03-07-2019 - |
Pregunta
Tengo problemas al suplantar a un usuario. Tengo un método declarado así:
[PrincipalPermission(SecurityAction.Demand, Name=@"DJPITER-PC\Test", Role="LocalTestGroup")]
static void LocalTestGroupOnly()
{
Console.WriteLine("Inside LocalTestGroupOnly() - {0}",
WindowsIdentity.GetCurrent().Name);
}
El código de llamada es:
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.");
}
El usuario predeterminado NO es miembro de LocalTestGroup. Usuario indicado por el token IS miembro de LocalTestGroup.
El problema:
La primera llamada a LocalTestGroupOnly () se realiza correctamente porque el usuario indicado por el token IS es miembro de LocalTestGroup. La segunda llamada (como usuario predeterminado) a LocalTestGroupOnly () debería fallar porque el usuario predeterminado no es 'Test' y no pertenece a LocalTestGroup. El problema es que este método también tiene éxito.
Si ejecuto el programa por separado, con y sin suplantación, el comportamiento es correcto: tiene éxito cuando se hace pasar por 'Prueba' y falla cuando llama como usuario predeterminado.
¿Cuál es el problema aquí?
Solución
¿Podría marcar Thread.CurrentPrincipal.Identity
en lugar de WindowsIdentity.GetCurrent ()
? PrincipalPermission.Demand ()
usa el primero.
Para cambiar Thread.CurrentPrincipal
(o HttpContext.User
) parece que debe configurarlos explícitamente después de la suplantación o después de deshacer. Consulte aquí para una pregunta similar .