Декларативные требования безопасности - кэшируется ли SecurityAction.Demand?

У меня проблема при выдаче себя за пользователя. У меня объявлен такой метод:

[PrincipalPermission(SecurityAction.Demand, Name=@"DJPITER-PC\Test", Role="LocalTestGroup")]
static void LocalTestGroupOnly()
{
    Console.WriteLine("Inside LocalTestGroupOnly() - {0}", 
        WindowsIdentity.GetCurrent().Name);
}

Телефонный код:

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.");
    }

Пользователь по умолчанию НЕ является членом LocalTestGroup. Пользователь, указанный токеном, является членом LocalTestGroup.

Проблема:

Первый вызов LocalTestGroupOnly () завершается успешно, поскольку пользователь, указанный токеном, является членом LocalTestGroup. Второй вызов (как пользователь по умолчанию) LocalTestGroupOnly () должен завершиться ошибкой, поскольку пользователь по умолчанию не является «Test» и не принадлежит LocalTestGroup. Проблема в том, что этот метод тоже удачный.

Если я запускаю программу отдельно - с олицетворением и без него, поведение будет правильным: оно будет успешным при олицетворении «Тест» и не работает при вызове от имени пользователя по умолчанию.

В чем проблема?


person pkolodziej    schedule 04.05.2009    source источник


Ответы (1)


Не могли бы вы проверить Thread.CurrentPrincipal.Identity вместо WindowsIdentity.GetCurrent()? PrincipalPermission.Demand() использует первое.

Чтобы изменить Thread.CurrentPrincipal (или HttpContext.User), кажется, что вы должны установить их явно после олицетворения или после отмены. Аналогичный вопрос см. здесь .

person Ronald Wildenberg    schedule 05.05.2009
comment
Действительно: после context.Undo () мне пришлось добавить Thread.CurrentPrincipal = new WindowsPrincipal (WindowsIdentity.GetCurrent ()); Почему этого не сделал метод Undo ()? Кажется, я не совсем понимаю Thread.CurrentPrincipal и WindowsImpersonationContext ... - person pkolodziej; 05.05.2009
comment
Я просмотрел несколько примеров, и все они явно устанавливают Thread.CurrentPrincipal при олицетворении. Я добавил к своему ответу дополнительную информацию. - person Ronald Wildenberg; 05.05.2009