Приоритетная высота в веб-приложении MVC3 с проверкой подлинности Windows

У меня есть требование реализовать повышение привилегий пользователей в веб-приложении MVC3 для обеих форм и проверки подлинности Windows, но этот вопрос имеет решающее значение для Windows auth. Это для более высокоприоритетного пользователя, чтобы предоставить помощь более низкоприоритетному пользователю, например. когда канцелярский пользователь выполняет задачу и требует, чтобы пользователь-администратор выполнял задачу до того, как канцелярский пользователь может продолжить, пользователь-администратор должен иметь возможность поднять один и тот же сеанс до уровня привилегий, выполнить задачу администратора и восстановить нижнюю привилегию к сеансу. Я не вижу здесь никакого пути, когда администратор отключается, а пользователь администратора регистрируется, учитывая, что мы хотим достичь этого на рабочем столе только клерикального пользователя. Возможно, пользовательское переключение является более аккуратным, чем целый новый сеанс, но мне очень хотелось бы "запустить как" эквивалент для веб-приложений, прошедших проверку подлинности Windows.

Возможно ли это, и если да, то как я могу это достичь? Я даже не знаю, где даже начать искать.

ОТВЕТЫ

Ответ 1

Вы можете разместить якорь где-нибудь на своем сайте:

@Html.ActionLink("elevate to admin", "SwitchToAdmin", "Home")

а затем действие контроллера, которое позволит ввести учетные данные администратора:

public ActionResult SwitchToAdmin()
{
    // TODO: Adjust the role name that your administrators will have
    if (!User.IsInRole(@"DOMAIN\Administrators"))
    {
        // The user is not currently an admin => popup a Logon box
        // so that the administrator could authenticate himself
        return new HttpUnauthorizedResult();
    }
    else
    {
        // After inputting the correct username and password for the
        // admin, we can now redirect to the home action and start performing
        // the admin tasks
        return RedirectToAction("index", "home");
    }
}

Процесс возврата будет обратным. У вас может быть ссылка, которая вызовет действие контроллера, которое будет вызывать 401, если пользователь является администратором, позволяя обычным пользователям вводить свое имя пользователя и пароль.

Ответ 2

Разрешить "полномочному пользователю" временно устанавливать определенную роль для других пользователей и, например, устанавливать также истечение срока действия с помощью DateTime.

Ответ 3

Чтобы использовать аутентификацию Windows для этого, я думаю, вам понадобится:

  • выполнить как команду
  • Ярлык на рабочем столе пользователя для запуска другого входа
  • Либо пакет script, чтобы запрашивать информацию о входе в систему пользователя или отдельную настольную программу для сбора информации (ярлыки указывают на любой из них, которые вы выберете)
  • Как только информация для командной строки run as готова, вы можете либо запустить браузер, либо, возможно, специальную программу со встроенным браузером.

Преимущество программы со встроенным браузером заключается в том, что она может иметь дополнительные меры предосторожности, такие как принудительное закрытие после таймаута.

В любом случае это одно из возможных решений. Вы также можете попытаться найти более сложный способ решения бизнес-задач. Возможно, сеанс удаленного рабочего стола для администратора?

Ответ 4

В качестве эквивалента команды run as используется пользовательское олицетворение. Это работает с командами, требующими более высоких привилегий в качестве другого пользователя. Он должен работать следующим образом: 1) Пользователь пытается получить доступ к привилегированным ресурсам. Webapp обнаруживает это либо потому, что у него есть своя таблица всех задач, требующих более высоких привилегий, или путем перехвата исключения безопасности, которое он пытается выполнить. 2) Когда это обнаружено, вы бросаете "RequiresPrivilegesElevationException" (исключение, которое вы должны определить). Это исключение, которое я выбрал контроллером, теперь знает, что он должен запрашивать у пользователя более высокие привилегии 3) контроллер запрашивает у пользователя пароль администратора (или более высокий пароль) 4) когда пользователь отправляет credentilas (через https), учетные данные используются для создания контекста олицетворения, и все операции выполняются в этом контексте олицетворения.

Недостатком такого подхода является то, что учетные данные и привилегия превышают только одну поездку на сервер... для любого другого запроса пользователь вынужден повторно вставить учетные данные. БЕЗОПАСНЫЙ ПУТЬ ИЗБЕЖАТЬ ЭТОГО из-за ограничений браузера безопасности