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

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

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

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

Разве это не AZMan 2003 года?

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

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

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

Конструктор объявлен как явный, что означает, что он не будет использоваться для неявного приведения типов. Неявное преобразование в auto_ptr может легко привести к нежелательным ситуациям, поскольку auto_ptr становится владельцем указателя.

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

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

    [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 

}

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

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