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

используем (3). На самом деле это помогло нам в сценарии интеграции синхронизировать учетные записи с

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

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

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

в LDAP кого? Это бесплатно, кросс-plaftorm, прост в использовании и администрировании удаленно, имеет мосты к другим схемам auth и привязки на других языках, которые вы знали, существовали...

разве Азман не из 2003?

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

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

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

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

решение 3.

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

что-то типа:

    [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 

}