Подтвердить что ты не робот

Должны ли мы разработать заказчик членства в этом случае?

Резюме

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

Наше приложение

У нас есть довольно старое приложение asp.net, которое устанавливается в местах расположения клиентов для обслуживания клиентов в локальной сети. Админы создают пользователей (пользователи не регистрируются), и в зависимости от установки у нас может быть интегрировано программное обеспечение с LDAP.

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

Администраторы могут назначать пользователей в 1 группу, и они могут изменять авторизацию этой группы для управления доступом к различным частям программного обеспечения.

Группы поддерживаются админами (веб-интерфейс), и, как было сказано ранее, предоставлены/запрещены разрешения для определенных функций внутри приложения.

Все это было полностью записано с нуля без использования встроенной авторизации или аутентификации .net. У нас буквально есть методы IsLoggedIn(), которые проверяют вход в систему и перенаправляют на нашу страницу входа в систему, если это не так.

Наша перепись

Нам было поручено более тесно интегрироваться с LDAP, они хотят, чтобы мы связывали группы в нашем приложении с группами (или любыми типами контейнеров, которые использует LDAP) в LDAP, чтобы, когда клиент решил использовать нашу интеграцию LDAP, они не должны управлять своими пользователями в LDAP и в нашем приложении.

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

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

Наша проблема

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

В принципе, я ищу совет, должен ли мы использовать поставщик членства ASP.NET и API управления ролями или мы должны продолжать сворачивать наши собственные? Я знаю, что это решение будет зависеть от наших требований, поэтому я перехожу через них ниже

Наши требования

Просто быстрый n грязный список

  • Поддерживайте способность иметь db пользователей и аутентифицировать их и предоставлять администраторам (только, а не пользователям) возможность пользователей CRUD
  • Разрешить сайту интегрироваться с LDAP, когда это выбрано, они не хотят, чтобы какие-либо пользователи, хранящиеся в БД, только отношения между группами, как они существуют в нашем приложении /db, и Группы/Контейнеры, поскольку они существуют в LDAP.
  • .net 3.5 используется (сочетание веб-форм asp.net и asp.net mvc)
  • Должен работать в ASP.NET и ASP.NET MVC (не должен быть проблемой, я предполагаю)
  • Это не может быть ориентировано на пользователя, администраторы должны быть единственными CRUD (или импортировать через ldap) пользователей и групп.
  • Мы должны иметь возможность Auth через LDAP, когда он настроен для этого

Я всегда стараюсь внимательно следить за своими вопросами, поэтому не стесняйтесь обращаться за дополнительной информацией. Кроме того, как общее резюме того, что я ищу в ответе, просто. "Вы должны/не должны использовать xyz, вот почему".

Ссылки, касающиеся провайдера членства asp.net и управления ролью, очень приветствуются, большинство вещей, которые я нахожу, составляет 5+ лет.

4b9b3361

ОТВЕТЫ

Ответ 1

Безопасность в контексте вашей проблемы включает в себя две отдельные операции: аутентификация и авторизация, а те, которые разделены на .NET, входят в MembershipProviders и RoleProviders. Я бы настоятельно рекомендовал использовать оба (то есть пользовательские или встроенные) для вашей аутентификации и авторизации. Это даст вам путь к обновлению, если вы позже найдете лучшие инструменты для выполнения задания и упростите другим разработчикам понимание безопасности.

Теперь, для проверки подлинности, я бы, как утверждали другие, использовал либо SqlMembershipProvider, либо ActiveDirectoryMembershipProvider. Мой опыт заключается в том, что в 99% случаев ActiveDirectoryMembershipProvider обеспечивает достаточную функциональность для того, что необходимо при работе с полным хранилищем AD (то есть не ADAM, а также в режиме ActiveDirectory Application Mode). У меня были проблемы с ActiveDirectoryMembershipProvider в многодоменных ситуациях, но в целом найти способ использования, а не сворачивать свои собственные, намного лучше. Аналогично, SqlMembershipProvider для аутентификации работает хорошо и хорошо масштабируется.

Авторизация, однако, является совершенно другим чайником рыбы. Это действительно то, где ваша боль будет ощущаться. Во-первых, нет "ActiveDirectoryRoleProvider". Это означает, что если вы хотите интегрироваться с группами AD, у вас есть три варианта:

  • Использовать AzMan
  • Сделайте это самостоятельно с помощью настраиваемого RoleProvider
  • Найдите человека, который сделал это за вас.
  • Используйте ADFS или новые федеративные службы Microsoft.

Выбор 1: AzMan AzMan (диспетчер авторизации) (см. также диспетчер авторизации Windows) это инструмент, который Microsoft написала для управления авторизацией приложений. AzMan обладает рядом приятных функций:

  • Он может связывать ваши роли с группами AD (или группами Windows)
  • Он может храниться как файл, поэтому вы можете сохранить его с помощью приложения.
  • Красиво разбивает авторизацию на задачи, операции и роли.
  • Поставляется с отдельным административным инструментом
  • Версия 2008 будет взаимодействовать с хранилищами проверки подлинности SQL.

Уловка заключается в том, что AzMan может быть медведем, чтобы развиваться против, и понимание этого инструмента не для тех, кто не испытывает. Я обнаружил, что документация скудная, но это было несколько лет назад. Кроме того, AuthorizationStoreRoleProvider не поддерживает задачи, даже если сам AzMan делает. Задачи - это наиболее гранулированные вещи, которые могут быть выполнены, и группируются в Операции, которые сами могут быть сгруппированы в роли, в которые могут быть удалены пользователи или группы AD. Документация стала немного лучше. Я действительно знаю, что, когда я в последний раз работал с AzMan, отсутствие взаимодействия наследования с хранилищем для проверки подлинности базы данных затрудняло работу.

Выбор 2: напишите свой собственный RoleProvider

Это может быть болезненным опытом работы с LDAP. Вам понадобится только настраиваемый RoleProvider в случае, когда вы хотите запросить группы AD и не хотите использовать AzMan, если вы планируете использовать SqlRoleProvider в средах, отличных от AD.

Другая альтернатива, которую я использовал, - управлять ролями в базе данных и позволять MembershipProvider быть тем, что она хочет. Это по-прежнему влечет за собой создание настраиваемого поставщика (но значительно более простого), что упрощает перенос приложения в среду AD с небольшим количеством беспорядков. Если вы храните роли в базе данных, и если вы хотите разрешить администраторам связывать несколько уровней групп с вашими ролями, тогда вам придется записать это в свой собственный RoleProvider.

Если вы планируете использовать SqlRoleProvider, вы также можете столкнуться с несколькими проблемами. Если вы используете SqlRoleProvider с SqlMemberProvider в одной прикладной среде, то он будет работать очень хорошо и очень прост в настройке. Однако, если у вас есть несколько приложений, которые вы хотите аутентифицировать в одном хранилище, то SqlRoleProvider не будет корректно работать во всех случаях без изменений.

Выбор 3: найдите того, кто сделал это для вас.

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

Выбор 4: Active Directory Federated Services

Microsoft действительно продвигает это решение, которое обещает единый вход, если вы можете заставить его работать. Уловкой для этого решения становится настройка, особенно между вами и партнером.

Ответ 2

Мне очень понравилось использование классов провайдера и роли поставщика. Они просто работают. Наилучшая часть, на мой взгляд, заключается в том, что для моей локальной разработки я использую поставщика SQL для входа в локальную базу данных, которая имеет те же имена пользователей, что и некоторые из тех, кого я хочу проверить (Admin, расширенный пользователь, базовый пользователь) с помощью общих паролей. Затем, когда я публикую свое приложение, он использует провайдер членства ActiveDirectory и легко интегрируется. Мне не нужно менять один кусок кода для ограничений доступа. (За исключением различий между моими файлами web.config)

В вашей ситуации лучше всего написать собственный пользовательский поставщик, просто потому, что вы хотите открыть пользователя в своей базе данных, но сравнить свой пароль с LDAP. Кроме того, они легко интегрируются как с Webforms, так и с MVC.

Я бы порекомендовал Scott Mitchell Multipart Серия для поставщиков. Очень обширный и тщательный.

Также я бы добавил, что только потому, что некоторые из статей являются старыми, не означает, что они еще не применяются. Структура провайдера членства существует уже несколько лет, поэтому имеет смысл, что некоторые из статей собирают пыль Ethernet.

Ответ 3

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

Быстрый ответ заключается в том, что, учитывая ваши требования, я собираюсь предложить вам изучить два встроенных поставщика, которые Microsoft предоставляет вам: на основе SQL Server и Active Directory. Из коробки, просто перевернув некоторую конфигурацию в вашем файле .config, вы можете переключить переключатель с помощью SQL Server на Active Directory. Если я не понимаю ваши потребности, может показаться, что это именно то, что вам нужно в двух ваших сценариях. Если вы сделаете это так, 100% вашего приложения могут выглядеть и работать одинаково, даже с той же кодовой базой. Миграция данных из существующего приложения одного развертывания в другое становится более интересной (и, к сожалению, у меня нет опыта в этом), но чистое развертывание одного и другого должно быть довольно простым.

Теперь, очевидно, если вам не нравится поведение встроенных поставщиков, вы можете создать свой собственный.

Где я нахожусь в своей работе, так это то, что мы использовали поставщика на основе SQL, и нам нужно перейти в Active Directory, и встроенный провайдер может быть или не быть достаточным для наших нужд (я все еще оцениваю, что, и очень активен в этом в данный момент). Я также работал с некоторым кодом доказательной концепции, чтобы в случае, когда нам это нужно, я уверен, что мы можем разумно создать наш собственный провайдер.

Итак, я знаю, что это не совсем ответ на ваш вопрос, но я надеюсь, что это даст вам кое-что о чем подумать и поможет вам каким-то образом. Как я уже сказал, я рад добавить к этому больше, так как я сам выражаю знание.

Ответ 4

Материал FYI

[Как сделать:] Создать пользовательский поставщик членства? - Видеоурок с официального сайта ASP.Net. Очень приятное введение в тему.

Простой провайдер членства LDAP - Сообщение форума о очень простом поставщике членства в LDAP.

GPL.Net Поставщик членства LDAP - это GPL, поэтому он может не работать для коммерческих приложений. Также некоторое время не работал. Но я думаю, это все еще стоит упомянуть.

Примечания

  • Возможно, вам придется бороться с соблазном клиентов использовать LDAP в качестве базы данных. Будь сильным! LDAP может использоваться для аутентификации и даже авторизации. Но в конечном итоге вам может понадобиться хранить намного больше информации. Единственный разумный способ сделать это - сопоставить ваш LDAP uid с таблицей пользователей базы данных и отключить его. Поставщик членства может сделать это прозрачным для остальной части вашего проекта. Но клиент должен понимать, что хотя LDAP предоставляет им единый вход, он не должен использоваться в качестве замены базы данных.

  • Лично я буду придерживаться API членства, но попробую написать исполняемый файл. Возможно, что-то немного кэшируется и автоматически отображает пользователей LDAP в таблицу пользователей базы данных на uid в качестве ключа. Хорошая вещь о LDAP - это немного поддержка в .NET. Вам не придется управлять сокетами и т.д., Если вы этого не хотите. Из-за этого мой код доступа к каталогу LDAP/обычно находится под десятком строк в одном методе. И это часто достаточно хорошо для производства.

Ответ 5

Просто, чтобы бросить еще одну идею в кольцо - считаете ли вы федеративную аутентификацию и авторизацию на основе требований? Похоже, что это хорошо подходит для вашего сценария. В основном это позволяет отделить аутентификацию от вашего приложения от поставщика услуг федерации (думаю, OpenID), который управляет аутентификацией и выдает токен вашему приложению. Доступны поставщики услуг, которые будут интегрированы с LDAP, AD и другими стандартами каталогов. ADFS (службы федерации Active Directory, ранее Женевский сервер) - один из примеров, который связывается с AD.

При правильной настройке свойства, связанные с идентификатором, такие как членство в группе, могут быть переданы вашему приложению как "претензия", связанная с личностью, - ваше приложение может делать то, что ему нравится, с требованием. Дело в том, что ваше приложение может узнать, к каким группам принадлежит пользователь, и к другим свойствам, например. адрес электронной почты, просмотрев претензии, которые передаются в токене.

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

Ознакомьтесь с http://msdn.microsoft.com/en-us/magazine/ee335707.aspx для ознакомления с Windows Identity Foundation (ранее кодовым названием "Женевская рамочная программа" ). Или просмотрите блог команды.