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

Question

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

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

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

Так что в основном три варианта, я думаю:

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

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

Во-вторых - есть ли еще варианты, которые мне не хватает?

благодарит за любые намеки, указатели, мнения!

Марк

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

Answer 1

На самом деле, ответ, вероятно, сочетание 1 и 3.

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

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

---

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

}

Answer 8

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

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