Авторизация asp.net mvc с использованием ролей

Я создаю приложение asp.net mvc, которое имеет концепцию пользователей. Каждый пользователь может редактировать собственный профиль. Например:

PersonID = 1 может редактировать свой профиль, перейдя в http://localhost/person/edit/1
PersonID = 2 может редактировать свой профиль, перейдя в http://localhost/person/edit/2

Ничего особенного в этом нет...

Тем не менее, я столкнулся с некоторыми проблемами в схеме авторизации. Сейчас в системе есть только две роли: "Администратор" и "DefaultUser", но скорее всего будет больше в будущем.

Я не могу использовать обычный атрибут Authorize для указания авторизации, потому что оба пользователя находятся в одной и той же роли (т.е. "DefaultUser" ).

Итак, если я задаю фильтр авторизации следующим образом:

[Authorize(Roles = "DefaultUser")]

то эффект не будет. PersonID = 1 может войти и отредактировать свой собственный профиль (как они должны быть), но они также могут просто изменить URL-адрес на http://localhost/person/edit/2 и у них есть полный доступ к редактированию профиля PersonID = 2 (что они не могут сделать).

Означает ли это, что я должен создать свой собственный фильтр авторизации, который проверяет, действительно ли действие, которое пользователь запрашивает "принадлежит" им, прежде чем разрешить им доступ? То есть, если действие редактирования с параметром = 1 запрашивается личным персоналом в настоящий момент, нужно ли выполнить пользовательскую проверку, чтобы убедиться, что личный пользователь в настоящий момент является PersonID = 1, и если да, авторизуйте их, а если нет, запретите доступ?

Похоже, что мне не хватает чего-то очевидного здесь, поэтому любое руководство будет оценено.

Ответ 1

Возможно, вы могли бы организовать действие контроллера таким образом, чтобы URL-адрес был больше похож на http://localhost/person/editme и отображает форму редактирования для текущего журнала - на пользователя. Таким образом, пользователь не может взломать URL-адрес, чтобы изменить кого-то другого.

Ответ 2

Мои $.02:

Авторизованные и аутентифицированные - это две разные вещи. Проще говоря, вопрос в том, можете ли вы это сделать, вы должны это делать? Вы можете забрать своих друзей, вы можете выбрать свой нос, но вы не можете выбрать нос ваших друзей! Там нет необходимости проверять авторизацию, если каждая роль может это сделать (у пользователя есть рука и нос). Имейте метод Post для пользователей, чтобы перейти к их собственному профилю и проверить идентификатор профиля с формой скрытых значений или перенаправить (а не нос, уйдите).

У вас есть метод Get для редактирования других профилей и просто проверьте роль администратора здесь - (я врач, я уполномочен придерживаться вашего носа)...

Ответ 3

Более элегантным решением было бы написать собственный фильтр действия авторизации, либо расширив [Авторизовать], либо выполнив IAuthorizationFilter следующим образом:

public class AuthorizeOwnerAttribute: FilterAttribute, IAuthorizationFilter
{
    #region IAuthorizationFilter Members

    public void OnAuthorization(AuthorizationContext filterContext)
    {
        // add logic here that compares the currently logged in user, to the owner of the profile that is being edited
        // get currently logged in user info from filterContext.HttpContext.User.Identity;
        // get profile being edited from filterContext.RouteData or filterContext.Something
    }

    #endregion
}

Я не уверен, какова бы логическая логика заключалась в методе OnAuthorization, но мои комментарии должны дать вам отправную точку. Вам придется обратиться к Google, чтобы узнать больше - как перенаправить пользователя на другое представление или бросить строго типизированное исключение, которое обрабатывается где-то в другом месте (возможно, в атрибуте [HandleError]).

Ответ 4

Мэтт прав.

Для чего предназначена авторизация, это показать, что им разрешено выполнять эту функцию. То, что вы пытаетесь сделать, это сказать, могут ли они выполнять функцию для этого конкретного идентификатора.

Итак, два решения:

Как сказал Мэтт, выполните действие, которое не принимает идентификатор, но просматривает текущего зарегистрированного пользователя из информации о сеансе и извлекает их.
Сделайте действие, которое принимает идентификатор, но разрешает доступ администраторам, поэтому при необходимости может изменять информацию других пользователей.

Но чтобы ответить на вопрос, Авторизация должна только сказать "Да, этот человек может использовать действие пользователя изменения", а не на основе введенного параметра.

Другим способом является то, что вы можете заставить его проверить, что пользователь восстановил == текущий пользователь, или перенаправить на другое действие, заявив, что они не могут редактировать этого пользователя, - но было бы лучше просто обеспечить действие, t принимает идентификатор и просто получает текущего зарегистрированного пользователя.

Ответ 5

Решение этой проблемы: http://nerddinnerbook.s3.amazonaws.com/Part9.htm

"Использование свойства User.Identity.Name при редактировании обедов

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