Какие схемы аутентификации и авторизации вы используете - и почему?

Ответ 1

Собственно, ответ, вероятно, представляет собой комбинацию 1 и 3.

Вы можете воспользоваться множеством инструментов и функций, которые предоставляет инфраструктура, написав членство, роль или профиль, если параметры по умолчанию не совсем доходят до вас 'd like.

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

Большинство людей, вероятно, отправляются на 3 из-за необходимости аутентификации поверх необработанного TCP - это вводит уровень, превышающий уровень стандартного поставщика ASP.NET.

Большая часть того, что MS производит "нормально" или "достаточно хорошо", но всегда будут случаи кросс, где вы хотите сделать что-то "не совсем стандартное", что означает, что вы в конечном итоге сворачиваете свои собственные. Я предполагаю, что у вас есть что-то помимо "Basic Auth" или "Windows Auth", которое было просто для вашего среднего разработчика, чтобы понять, они взяли разумный вариант "позволяет просто построить это для Интернета".

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

Тем не менее, роли по умолчанию и поставщики профилей довольно ограничены (роли: нет иерархии, поэтому вам нужно проверить каждую возможную роль или явно назначить каждую роль пользователю; профили: все сохраненные в одном поле как разделенные запятыми значения - нелегко найти всех пользователей, у которых есть набор значений).

Ответ 2

Воспользуемся (3). Фактически это помогло нам в интеграционном пейзаже синхронизировать учетные записи с

• бизнес-процессы
• Другие системы (не все в одном стеке технологий (ASP.NET))

Ответ 3

В недавнем проекте мы расширили провайдер членства ASP.NET(написал пользовательский поставщик) с целью использования некоторых элементов управления на основе роли для управления разрешениями. Теперь, когда проект созрел достаточно, мы обнаруживаем, что элементы управления недостаточно гибки для наших требований, и в какой-то степени мы сожалеем о том, что спустились по пути членства в MS. Лучше всего использовать свою собственную аутентификацию, если у вас есть время для ее правильного архивирования.

Похоже, что ваше приложение немного гибрид в том, что вы обслуживаете внутренних и внешних клиентов, но, возможно, также уделяете некоторое внимание интеграции OpenID для ваших внешних клиентов. Есть некоторые отличные элементы управления OpenID ASP.NET, которые действительно делают обработку новых учетных записей для внешних клиентов без проблем. Это, конечно, зависит от того, насколько "общедоступна" ваша заявка.

Ответ 4

Ldap кто-нибудь? Он бесплатный, кросс-plaftorm, простой в использовании и администрировании удаленно, имеет мосты для других схем аутентификации и привязки на более известных языках, которые вы знали...

Ответ 5

Не является ли AZMan с 2003 года?

Я бы порекомендовал 1 или 3. Лично я всегда ходил на 3. Там много функциональности, которая 1 имеет то, что я не использую или не использую.

Ответ 6

Я бы держался подальше от AzMan. Мы однажды пошли по этой дороге и не понравились раздел города, в который мы вломились. Мы всегда работали с входами на основе AD, которые используют SID текущего пользователя для связи с пользователем в базе данных, а затем получили разрешения оттуда. Учитывая вашу настройку, это может оказаться невозможным (или практичным), но я остался бы в стороне от AzMan в любом случае.

Ответ 7

Я не разработчик ASP или .NET, но моя кишка говорит (3). Вы действительно не хотите, чтобы общедоступное веб-приложение имело какой-либо доступ к вашей корпоративной сети, а тем более не позволяло вводить учетные данные аутентификации в любой точке AD.

Ответ 8

Кажется, вы слишком много и слишком расширяемы, чтобы придерживаться одного технологического решения

Решение 3.

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

Что-то вроде:

    [ClassAttribute ( "Yordan Georgiev", "1.0.2", "20090302", "20090415" , false )]
public class User
{
    #region DomainName
    private string _DomainName;
    public string DomainName
    {
        get { return _DomainName; }
        set { _DomainName = value; }
    } //eof property DomainName 


    #endregion DomainName

    #region Status
    private int _Status;
    public int Status
    {
        get { return _Status; }
        set { _Status = value; }
    } //eof property Status 


    #endregion Status

#region Password
    private string _Password = Resources.GV.Pass; 
    public string Password
    {
        get { return _Password; }
        set {
            _Password = GenApp.Utils.Security.Encryptor.Encrypt ( value,
                GenApp.Conf.GenAppSettings.Instance.EncryptionAlgorithm );
            //debug_Password = value; //unencrypted 
        }
    } //eof property Password 


    #endregion Password 

#region ListUserRoles
        private List<UserRole> _ListUserRoles;
        public List<UserRole> ListUserRoles { get { return _ListUserRoles; } set     { _ListUserRoles = value; } }
        #endregion ListUserRoles


    #region UserSettings
    private GenApp.Conf.UserSettings _UserSettings;
    public GenApp.Conf.UserSettings UserSettings
    {
        get {
            if (_UserSettings == null)
                _UserSettings = (GenApp.Conf.UserSettings)GenApp.Conf.GenAppSettings.Instance;

            return _UserSettings; 
        }
        set { _UserSettings = value; }
    } //eof property UserSettings 

}