Подтвердить что ты не робот

Как я могу вручную проверить авторизацию URL в MVC5?

IIS-Manager

IIS-ManagerЧтобы ограничить доступ к веб-приложению, администратор может установить URL-авторизацию пользователей и групп с помощью диспетчера IIS:

IIS Autohrization Rules

Web.config

IIS-Manager сохраняет правила авторизации в файле web.config приложения:

<security>
  <authorization bypassLoginPages="true"> 
    <remove users="*" roles="" verbs="" />
    <add accessType="Allow" users="Testuser" />
    <add accessType="Deny" users="*" /> 
  </authorization>
</security>

Когда для bypassLoginPages установлено значение true, всем пользователям разрешается доступ к странице входа в систему. Когда пользователь не вошел в систему, он автоматически будет перенаправлен на страницу входа:

<authentication mode="Forms">
  <forms [...] loginUrl="~/Auth/Login" [...] >
    [...]
  </forms>
</authentication>

Приложение MVC5:

Пользователь должен войти в систему через пользовательскую страницу входа в систему под своим Windows SamAccountName и паролем. Учетные данные будут отправлены в действие Login AuthController:

[AllowAnonymous]
public class AuthController : Controller
{
    public ActionResult Login
    {
        // validation of SamAccountName and Password against Active Directory here.

        [...]

        // We want to check the authorization here.

        // create authentication ticket
        FormsAuthenticationTicket lFormsAuthenticationTicket = new FormsAuthenticationTicket(1,
            SamAccountName,
            DateTime.Now,
            DateTime.Now.AddMinutes(AuthCookieTimeout),
            RememberMe,
            CustomData,
            FormsAuthentication.FormsCookiePath);

        // Encrypt the ticket.
        string lEncryptedTicket = FormsAuthentication.Encrypt(lFormsAuthenticationTicket);

        var lAuthCookie = new HttpCookie(FormsAuthentication.FormsCookieName, lEncryptedTicket);

        // Create the cookie.
        Response.Cookies.Add(lAuthCookie);

        [...]

        return RedirectToAction("Index", "Main"); // redirect to the main controller
    }
}

Все контроллеры с ограниченным доступом автоматически проверяют авторизацию с помощью атрибута [Authorize]:

[Authorize]
public class MainController : Controller
{
    [...]
}

Украшение типа [Authorize(Users="User1,User2")] не является решением, потому что код недоступен для конечных пользователей, которые должны иметь возможность конфигурировать доступ к приложению.

Если пользователь не авторизован, он будет перенаправлен на страницу входа. Это отлично работает. Но мне нужно сделать проверку авторизации в действии Login раньше. Итак, мой вопрос:

Как я могу вручную проверить в AuthController, если вошедший в систему пользователь авторизован для перенаправления на MainController?

4b9b3361

Ответ 1

  Q: Как я могу вручную проверить в моем AuthController, если вошел в систему пользователь авторизован для перенаправления на MainController?

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

  • Ограничить доступ для аутентифицированных пользователей: [Authorize]
  • Ограничьте доступ некоторым конкретным пользователям: [Authorize(Users="User1,User2")]
  • Ограничьте доступ к некоторым конкретным ролям: [Authorize(Roles="Administrators,PowerUsers")]

Поскольку вы украсили MainController атрибутом Authorize, это означает, что никто не может получить доступ к его действиям без входа в систему. Таким образом, в действии Logon вам не нужно проверять, авторизован ли пользователь для перенаправления на главный контроллер. Здесь нет никаких недостатков безопасности, и вам не нужно беспокоиться об авторизации при использовании RedirectToAction("Index", "Main").

Q: Определение в атрибуте Authorize не решит проблема. Как администраторы могут ограничивать пользователей и группы, когда они купить программное обеспечение? У тебя нет доступа к коду.

Роли созданы для такого требования. Вы должны использовать [Authorize(Roles="Role1")] выше MainController, и тогда каждый пользователь Role1 может получить доступ к действиям основного контроллера. Это может быть просто сделано в управлении пользователями и ролями вашего приложения. Итак:

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

Примечание

В большинстве приложений роли статичны, и вы можете сказать, какая роль может иметь доступ к какому действию. В таких случаях текущего атрибута Authorize будет достаточно для авторизации. Просто добавьте пользователей в роли во время выполнения. Identity Samples содержит необходимые модели, представления и контроллеры для этого.

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

Ответ 2

Вы не должны использовать тег <authorization> в ASP.Net MVC. Он предназначен для веб-формы ASP.Net. Вы можете прочитать больше в fooobar.com/questions/175831/....

В ASP.Net MVC вы хотите использовать атрибут [Authorize]. Кроме того, вы хотите использовать промежуточное ПО OWIN вместо старого FormsAuthenticationTicket.

У него мало частей, поэтому я создал образец проекта в GitHub AspNetMvcActiveDirectoryOwin. Исходным сусом является аутентификация с помощью AD, но вам просто нужно настроить класс ActiveDirectoryService.

Следующие три являются основными классами -

Ответ 3

Две опции,

Используйте параметр "Роли" под Authorize следующим образом:

 [Authorize(Roles="TestUsers,Admins")]

Затем добавьте пользователей, которым должен быть разрешен доступ к этому действию для этих ролей. Роли предоставляются как часть ClaimsPrincipal, используемого ASP Identity.

Или, альтернативно, предоставите собственную реализацию атрибута Authorize, который проверяет зарегистрированного пользователя во всех существующих бизнес-правилах, а затем разрешает или запрещает доступ.