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

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

39 голосов
/ 16 апреля 2009

Мы начинаем разрабатывать целую кучу новых сервисов для создания (WCF, ADO.NET Data Services, возможно, в какой-то момент в облаке), и возникает один вопрос: какую схему аутентификации и авторизации использовать - там довольно много!

Нам необходимо уметь идентифицировать пользователей (реальных людей и «виртуальных» пользователей приложений / служб) по широкому спектру протоколов - HTTP, HTTPS, TCP - и нам нужно назначить им хотя бы несколько ролей. / разрешение на просмотр определенных данных и / или выполнение определенных операций.

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

Так что, в основном, есть три варианта:

  1. Использование системы членства ASP.NET - создавайте пользователей и назначайте там роли
  2. Используйте AzMan (менеджер авторизации), который представляется более детальной, более зрелой, более сложной системой (с пользователями, задачами, группами - три уровня, а не только пользователь + роли)
  3. Ролл наш

Прежде всего - какой из этих трех вы бы порекомендовали? Есть почему?

Во-вторых - есть ли еще варианты, которые я пропускаю?

Спасибо за любые подсказки, указатели, мнения!

Марк

PS: видя ответы до сих пор, я поражен количеством людей, голосующих за вариант № 3. Я бы подумал, что MS сможет разработать что-то повторно используемое, которое сможет удовлетворить все эти требования ....

Ответы [ 8 ]

19 голосов
/ 16 апреля 2009

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

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

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

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

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

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

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

6 голосов
/ 16 апреля 2009

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

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

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

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

1 голос
/ 16 апреля 2009

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

Решение 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

}

1 голос
/ 16 апреля 2009

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

1 голос
/ 16 апреля 2009

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

1 голос
/ 16 апреля 2009

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

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

1 голос
/ 16 апреля 2009

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

...