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

Выполнение пользовательской аутентификации, авторизации и ролей MVC

Потерпите меня, когда я подробно расскажу о проблеме...

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

Аутентификация

Существует три способа входа в систему: (1) Email + Alias, (2) OpenID и (3) Username + Password. Все три пользователя получают файл cookie auth и начинают сеанс. Первые два используются посетителями (только сессия), а третья для авторов /admin с учетными записями db.

public class BaseFormsAuthenticationService : IAuthenticationService
{
    // Disperse auth cookie and store user session info.
    public virtual void SignIn(UserBase user, bool persistentCookie)
    {
        var vmUser = new UserSessionInfoViewModel { Email = user.Email, Name = user.Name, Url = user.Url, Gravatar = user.Gravatar };

        if(user.GetType() == typeof(User)) {
            // roles go into view model as string not enum, see Roles enum below.
            var rolesInt = ((User)user).Roles;
            var rolesEnum = (Roles)rolesInt;
            var rolesString = rolesEnum.ToString();
            var rolesStringList = rolesString.Split(',').Select(role => role.Trim()).ToList();
            vmUser.Roles = rolesStringList;
        }

        // i was serializing the user data and stuffing it in the auth cookie
        // but I'm simply going to use the Session[] items collection now, so 
        // just ignore this variable and its inclusion in the cookie below.
        var userData = "";

        var ticket = new FormsAuthenticationTicket(1, user.Email, DateTime.UtcNow, DateTime.UtcNow.AddMinutes(30), false, userData, FormsAuthentication.FormsCookiePath);
        var encryptedTicket = FormsAuthentication.Encrypt(ticket);
        var authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket) { HttpOnly = true };
        HttpContext.Current.Response.Cookies.Add(authCookie);
        HttpContext.Current.Session["user"] = vmUser;
    }
}

Роли

Простой флажок enum для разрешений:

[Flags]
public enum Roles
{
    Guest = 0,
    Editor = 1,
    Author = 2,
    Administrator = 4
}

Расширение Enum для перечисления перечислений флагов (wow!).

public static class EnumExtensions
{
    private static void IsEnumWithFlags<T>()
    {
        if (!typeof(T).IsEnum)
            throw new ArgumentException(string.Format("Type '{0}' is not an enum", typeof (T).FullName));
        if (!Attribute.IsDefined(typeof(T), typeof(FlagsAttribute)))
            throw new ArgumentException(string.Format("Type '{0}' doesn't have the 'Flags' attribute", typeof(T).FullName));
    }

    public static IEnumerable<T> GetFlags<T>(this T value) where T : struct
    {
        IsEnumWithFlags<T>();
        return from flag in Enum.GetValues(typeof(T)).Cast<T>() let lValue = Convert.ToInt64(value) let lFlag = Convert.ToInt64(flag) where (lValue & lFlag) != 0 select flag;
    }
}

Авторизация

Служба предлагает методы проверки аутентифицированных ролей пользователя.

public class AuthorizationService : IAuthorizationService
{
    // Convert role strings into a Roles enum flags using the additive "|" (OR) operand.
    public Roles AggregateRoles(IEnumerable<string> roles)
    {
        return roles.Aggregate(Roles.Guest, (current, role) => current | (Roles)Enum.Parse(typeof(Roles), role));
    }

    // Checks if a user roles contains Administrator role.
    public bool IsAdministrator(Roles userRoles)
    {
        return userRoles.HasFlag(Roles.Administrator);
    }

    // Checks if user has ANY of the allowed role flags.
    public bool IsUserInAnyRoles(Roles userRoles, Roles allowedRoles)
    {
        var flags = allowedRoles.GetFlags();
        return flags.Any(flag => userRoles.HasFlag(flag));
    }

    // Checks if user has ALL required role flags.
    public bool IsUserInAllRoles(Roles userRoles, Roles requiredRoles)
    {
        return ((userRoles & requiredRoles) == requiredRoles);
    }

    // Validate authorization
    public bool IsAuthorized(UserSessionInfoViewModel user, Roles roles)
    {
        // convert comma delimited roles to enum flags, and check privileges.
        var userRoles = AggregateRoles(user.Roles);
        return IsAdministrator(userRoles) || IsUserInAnyRoles(userRoles, roles);
    }
}

Я решил использовать это в своих контроллерах через атрибут:

public class AuthorizationFilter : IAuthorizationFilter
{
    private readonly IAuthorizationService _authorizationService;
    private readonly Roles _authorizedRoles;

    /// <summary>
    /// Constructor
    /// </summary>
    /// <remarks>The AuthorizedRolesAttribute is used on actions and designates the 
    /// required roles. Using dependency injection we inject the service, as well 
    /// as the attribute constructor argument (Roles).</remarks>
    public AuthorizationFilter(IAuthorizationService authorizationService, Roles authorizedRoles)
    {
        _authorizationService = authorizationService;
        _authorizedRoles = authorizedRoles;
    }

    /// <summary>
    /// Uses injected authorization service to determine if the session user 
    /// has necessary role privileges.
    /// </summary>
    /// <remarks>As authorization code runs at the action level, after the 
    /// caching module, our authorization code is hooked into the caching 
    /// mechanics, to ensure unauthorized users are not served up a 
    /// prior-authorized page. 
    /// Note: Special thanks to TheCloudlessSky on StackOverflow.
    /// </remarks>
    public void OnAuthorization(AuthorizationContext filterContext)
    {
        // User must be authenticated and Session not be null
        if (!filterContext.HttpContext.User.Identity.IsAuthenticated || filterContext.HttpContext.Session == null)
            HandleUnauthorizedRequest(filterContext);
        else {
            // if authorized, handle cache validation
            if (_authorizationService.IsAuthorized((UserSessionInfoViewModel)filterContext.HttpContext.Session["user"], _authorizedRoles)) {
                var cache = filterContext.HttpContext.Response.Cache;
                cache.SetProxyMaxAge(new TimeSpan(0));
                cache.AddValidationCallback((HttpContext context, object o, ref HttpValidationStatus status) => AuthorizeCache(context), null);
            }
            else
                HandleUnauthorizedRequest(filterContext);             
        }
    }

Я украшаю действия в своих контроллерах с этим атрибутом и, как и Microsoft [Authorize], никакие параметры не позволяют никому пройти аутентификацию (для меня это Enum = 0, не требуемые роли).

Что касается обертывания фоновой информации (phew)... и написав все это, я ответил на свой первый вопрос. На данный момент мне интересно узнать о целесообразности моей установки:

  • Нужно ли вручную обманывать файл cookie auth и заполнять основную форму FormsIdentity для HttpContext или должно быть автоматическим?

  • Любые проблемы с проверкой подлинности в атрибуте/фильтре OnAuthorization()?

  • Что такое компромисс в использовании Session[] для хранения моей модели представления или ее сериализации внутри файла cookie auth?

  • Является ли это решение, похоже, достаточно хорошо "разделяющим идеалы"? (Бонус, поскольку это более ориентированный на мнение вопрос)

4b9b3361

Ответ 1

Перекрестная почта из моего ответа CodeReview:

Я возьмусь за ответ на ваши вопросы и даю несколько советов:

  • Если у вас есть функция FormsAuthentication, настроенная в web.config, она автоматически вытащит файл cookie для вас, поэтому вам не придется выполнять рутинное заполнение формы FormsIdentity. Это довольно легко проверить в любом случае.

  • Вероятно, вы хотите переопределить как AuthorizeCore, так и OnAuthorization для эффективного атрибута авторизации. Метод AuthorizeCore возвращает логическое значение и используется для определения того, имеет ли пользователь доступ к данному ресурсу. OnAuthorization не возвращается и обычно используется для запуска других вещей на основе состояния аутентификации.

  • Я думаю, что вопрос session-vs-cookie в значительной степени является предпочтительным, но я бы порекомендовал, чтобы он прошел сессию по нескольким причинам. Самая большая причина заключается в том, что файл cookie передается с каждым запросом, и хотя сейчас у вас может быть только немного данных, поскольку время прогрессирует, кто знает, что вы будете там набирать. Добавьте накладные расходы на шифрование, и он может стать достаточно большим, чтобы замедлить запросы. Хранение его на сеансе также позволяет владеть данными в ваших руках (по сравнению с тем, чтобы положить его в руки клиента и полагаться на вас, чтобы расшифровать и использовать его). Одно из предложений, которое я бы сделал, - это перенос этого сеанса в статический класс UserContext, похожий на HttpContext, поэтому вы можете просто позвонить, например UserContext.Current.UserData. Ниже приведен пример кода.

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

Последний вопрос: почему вы создали и установили cookie FormsAuthentication вручную вместо использования FormsAuthentication.SetAuthCookie? Просто любопытно.

Пример кода для класса статического контекста

public class UserContext
{
    private UserContext()
    {
    }

    public static UserContext Current
    {
        get
        {
            if (HttpContext.Current == null || HttpContext.Current.Session == null)
                return null;

            if (HttpContext.Current.Session["UserContext"] == null)
                BuildUserContext();

            return (UserContext)HttpContext.Current.Session["UserContext"];
        }
    }

    private static void BuildUserContext()
    {
        BuildUserContext(HttpContext.Current.User);
    }

    private static void BuildUserContext(IPrincipal user)
    {
        if (!user.Identity.IsAuthenticated) return;

        // For my application, I use DI to get a service to retrieve my domain
        // user by the IPrincipal
        var personService = DependencyResolver.Current.GetService<IUserBaseService>();
        var person = personService.FindBy(user);

        if (person == null) return;

        var uc = new UserContext { IsAuthenticated = true };

        // Here is where you would populate the user data (in my case a SiteUser object)
        var siteUser = new SiteUser();
        // This is a call to ValueInjecter, but you could map the properties however
        // you wanted. You might even be able to put your object in there if it a POCO
        siteUser.InjectFrom<FlatLoopValueInjection>(person);

        // Next, stick the user data into the context
        uc.SiteUser = siteUser;

        // Finally, save it into your session
        HttpContext.Current.Session["UserContext"] = uc;
    }


    #region Class members
    public bool IsAuthenticated { get; internal set; }
    public SiteUser SiteUser { get; internal set; }

    // I have this method to allow me to pull my domain object from the context.
    // I can't store the domain object itself because I'm using NHibernate and
    // its proxy setup breaks this sort of thing
    public UserBase GetDomainUser()
    {
        var svc = DependencyResolver.Current.GetService<IUserBaseService>();
        return svc.FindBy(ActiveSiteUser.Id);
    }

    // I have these for some user-switching operations I support
    public void Refresh()
    {
        BuildUserContext();
    }

    public void Flush()
    {
        HttpContext.Current.Session["UserContext"] = null;
    }
    #endregion
}

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

public class SiteUser
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string FullName
    {
        get { return FirstName + " " + LastName; }
    }
    public string AvatarUrl { get; set; }

    public int TimezoneUtcOffset { get; set; }

    // Any other data I need...
}

Ответ 2

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

Ответ 3

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