Безопасность Asp.net: IIdentity.IsAuthenticated реализация по умолчанию - PullRequest
Новая
       17

Безопасность Asp.net: IIdentity.IsAuthenticated реализация по умолчанию

1 голос
/ 27 апреля 2010

Я пишу свой собственный класс Identity, который реализует IIdentity. Мне не нужно менять метод IsAuthenticated по умолчанию, но теперь мне было интересно, как IIdentity по умолчанию определяет, должен ли он возвращать true или false?

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

Заранее спасибо,

Pickels

Ответы [ 2 ]

6 голосов
/ 27 апреля 2010

В контексте обработчика ASP.Net отсутствует 'default IIdentity'.

Существует GenericIdentity, который передается GenericPrincipal, который является значением по умолчанию User для обработчика ASP.Net, и его поведение таково, что если он создается с непустым именем пользователя, то он аутентифицируется .

, например 

public virtual bool IsAuthenticated
{
    get
    {
        return !this.m_name.Equals("");
    }
}

Тем не менее, определение IsAuthenticated совершенно произвольно, и класс, реализующий IIdentity, полностью отвечает за реализацию этой логики.

Как правило, не существует сценария использования для создания экземпляра неаутентифицированного принципала / удостоверения, поскольку это выполняется автоматически во время выполнения asp.net, таким образом, реализуя ваш пользовательский IIdentity с «тупым» IsAuthenticated, который возвращает true должно быть уместно в большинстве случаев.

Кроме того, хотя полная реализация IPrincipal и IIdentity тривиальна, вы также можете просто извлечь из GenericPrincipal и GenericIdentity сокращение объема кода, который вам нужно поддерживать.

В контексте FormsAuthentication у вас будет билет только в том случае, если пользователь аутентифицирован, а User будет экземпляром RolePrincipal с идентификатором типа FormsIdentity и его реализация IsAuthenticated супер сложный ;-) ... 

public bool IsAuthenticated
{
    get
    {
        return true;
    }
}

Надеюсь, это поможет прояснить ситуацию.

2 голосов
/ 27 апреля 2010

Я использую пользовательский UserPrinciple, чтобы встраивать на мои страницы больше информации о текущем пользователе, чем позволяет стандартный GenericPrinciple. Я не нашел необходимости реализовывать мой собственный IIdentity, так как вы можете легко использовать встроенный FormsIdentity аналогично моей моде (я не уверен, отличается ли это от стандартных практик Auth для .NET, он работал отлично хотя на практике для себя). Я создал пользовательский GuestIdentity, который возвращает жестко закодированный IsAuthenticated = false, возможно, его можно заменить просто GenericPrinciple Я не уверен, что он абстрактный или нет. 

public class UserPrincipal : IPrincipal
{            

  private readonly IIdentity _identity;

  public UserPrincipal()
        {
            _identity = new GuestIdentity();

            var guest = //my custom object
            User = guest;
        }        
    public UserPrincipal(HttpContext context)
    {
        var ident = context.User.Identity as FormsIdentity;
        string msg1 = "Context.User.Identity is null for authenticated user.";
        if (ident == null) throw new ApplicationException(msg1);

        _identity = ident;
        string msg2 = "Forms Identity Ticket is null";
        if (ident.Ticket == null) throw new AccessViolationException(msg2);

        var userData = ident.Ticket.UserData;

        ...

        User = jsonSerializer.Deserialize<User>(userJson);
    }    
    #region IPrincipal Members
    public bool IsInRole(string role)
    {
        return User.Roles.FirstOrDefault(x => x.RoleName == role) != null;
    }

    public IIdentity Identity
    {
        get { return _identity; }
    }
    #endregion
}

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

...