Мы должны разработать пользовательского поставщика членства в этом случае?
Сводка
Короче говоря, для нас определили задачу с потрошением частей аутентификации и авторизации довольно старого и чрезмерно увеличенного в размерах приложения asp.net, которое ранее имело все эти компоненты, записанные с нуля. Так как наше приложение не является типичным, и ни один из нас не имею опыт в asp.net, созданном в материале поставщика членства, мы не уверены, должны ли мы прокрутить нашу собственную аутентификацию и авторизацию снова или если мы должны попытаться работать в мышлении поставщика членства asp.net и разработать нашего собственного поставщика членства.
Наше приложение
У нас есть довольно старое приложение asp.net, которое установлено в местонахождениях заказчика для обслуживания клиентов на LAN. Администраторы создают пользователей (пользователи не подписываются), и в зависимости от установки, нам можно было интегрировать программное обеспечение с LDAP.
В настоящее время, групповой импорт интеграции LDAP пользователи к нашей базе данных и когда они входят в систему, это проходит проверку подлинности против LDAP, таким образом, мы не должны управлять их паролями. Ничто удивительное там.
Администраторы могут присвоить пользователей 1 группе, и они могут изменить авторизацию той группы управлять доступом к различным частям программного обеспечения.
Группы сохраняются Администраторами (веб-UI) и, как сказано ранее, предоставляются / отклоненные в полномочиях к определенной функциональности в рамках приложения.
Все это было полностью записано с нуля, не используя ни одного из созданных в авторизации .NET или аутентификации. Мы буквально имеем IsLoggedIn() методы, которые проверяют на вход в систему и перенаправление к нашей странице входа в систему, если они не.
Наш переписывать
Для нас определили задачу для интеграции более плотно с LDAP, они хотят, чтобы мы связали группы в нашем приложении группам (или безотносительно типов контейнеров, которые LDAP использует) в LDAP так, чтобы, когда клиентский opt's для использования нашей интеграции LDAP они не должны управлять своими пользователями в LDAP И в нашем приложении.
Новый путем они просто создадут пользователей в LDAP, добавьте их к Группам в LDAP, и наше приложение будет видеть, что они принадлежат соответствующей группе LDAP и аутентифицируют и авторизовывают их.
Кроме того, нам предоставили разрешение, чтобы полностью сорвать Аутентификацию пользователя и код авторизации и полностью восстановить его.
Наша проблема
Проблема состоит в том, что ни один из нас не имею опыта с функциональностью поставщика членства asp.net. Немного воздействия я имею к нему, заставляет меня волноваться, что это не было предназначено, чтобы использоваться для приложения такой как наш. Хотя, разрабатывая нашего собственного менеджера по Поставщику и Роли Членства ASP.NET кажется, что это был бы большой опыт и скорее всего соответствующая вещь сделать.
В основном я ищу совет, мы должны использовать поставщика Членства ASP.NET и Ролевое управление API, или мы должны продолжить прокручивать наше собственное? Я знаю, что это решение будет под влиянием наших требований, таким образом, я пробегусь через них ниже
Наши требования
Просто быстрый n грязный список
- Поддержите способность иметь дб пользователей и аутентифицировать их и дать администраторам (только, не пользователи) способность к пользователям CRUD
- Позвольте сайту интегрироваться с LDAP, когда это выбрано, они не хотят пользователей, сохраненных в DB, только отношения между Группами, поскольку они существуют в нашем приложении / дб и Группы/Контейнеры, как они существуют в LDAP.
- .net 3.5 используется (соединение веб-форм asp.net и asp.net mvc)
- Должен работать в ASP.NET, и ASP.NET MVC (не должна быть проблема, которую я предполагаю),
- Это не может быть ориентировано на пользователя, администраторы должны быть единственными, что CRUD (или импортируют через ldap), пользователи и группы
- Мы должны смочь Автору через LDAP когда его настроенный, чтобы сделать так
Я всегда пытаюсь контролировать свои вопросы тесно, так не стесняйтесь просить больше информации. Кроме того, поскольку общая сводка того, что я ищу в ответе, справедлива. "Необходимо использовать xyz, вот то, почему".
Ссылки относительно поставщика членства asp.net и ролевого материала управления очень приветствуются, большая часть материала, который я нахожу, равняется 5 + годы.
5 ответов
Безопасность в контексте вашей проблемы включает две отдельные операции: аутентификацию и авторизацию, которые в .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
Microsoft действительно продвигала это решение, которое обещает единый вход, если вы сможете заставить его работать. Уловка этого решения заключается в том, чтобы настроить его специально между вами и партнером.
Материал для справки
[Как мне:] Создать настраиваемого поставщика членства? - Видеоурок от официального представителя ASP.Net сайт. Очень хорошее введение в тему.
Простой поставщик членства в LDAP - сообщение на форуме очень простого поставщика членства в LDAP.
GPL .Net LDAP Membership Provider - это GPL, поэтому она может не работать для коммерческих приложений. Также давно не работал. Но, думаю, об этом все же стоит упомянуть.
Примечания
Возможно, вам придется побороть искушение клиентов использовать LDAP в качестве базы данных. Быть сильным! LDAP можно использовать для аутентификации и даже авторизации . Но со временем вам может понадобиться хранить гораздо больше информации. Единственный разумный способ сделать это - сопоставить ваш LDAP uid с таблицей пользователей базы данных и запустить ее. Ваш провайдер членства может сделать это прозрачным для остальной части вашего проекта. Но клиент должен понимать, что, хотя LDAP предоставляет им возможность единого входа, его не следует использовать в качестве замены базы данных.
Лично я бы придерживался API членства, но попытался бы написать производительный бэкэнд. Возможно, что-то вроде небольшого кэширования и автоматического сопоставления пользователей LDAP с таблицей пользователей базы данных на uid в качестве ключа. Что хорошо в LDAP, так это то, что он имеет небольшую поддержку в .Net. Вам не придется управлять сокетами и т. Д., Если вы действительно этого не хотите. Из-за этого мой код доступа к LDAP / каталогу обычно занимает менее десятка строк на метод. И этого часто бывает достаточно для производства.
Я был очень доволен простотой классов поставщика членства и поставщика ролей. Они просто работают. На мой взгляд, лучшая часть заключается в том, что для моей локальной разработки я использую поставщика SQL для входа в локальную базу данных, которая имеет те же имена пользователей, что и некоторые люди, которых я хочу протестировать как (администратор, продвинутый пользователь, базовый user) с общими паролями. Затем, когда я публикую свое приложение, оно использует поставщика членства ActiveDirectory и легко интегрируется.Мне не нужно менять ни один фрагмент кода для ограничения доступа. (За исключением различий между моими файлами web.config)
В вашей ситуации, кажется, лучше всего написать собственный пользовательский провайдер просто потому, что вы хотите обнаружить пользователя в своей базе данных, но сравнить его пароль с LDAP. Кроме того, они легко интегрируются как с Webforms, так и с MVC.
Я бы порекомендовал провайдерам серию Multipart Скотта Митчелла. Очень обширно и тщательно.
Также я хотел бы добавить, что то, что некоторые статьи устарели, не означает, что они еще не применимы. Структура поставщика членства отсутствует уже несколько лет, поэтому логично, что некоторые статьи собирают пыль с Ethernet.
Просто чтобы подбросить еще одну идею - у вас рассмотрели федеративную аутентификацию и авторизацию на основе утверждений? Похоже, это может хорошо подойти для вашего сценария. По сути, это позволяет вам отделить аутентификацию от вашего приложения до федеративного поставщика услуг (например, OpenID), который управляет аутентификацией и выдает токен вашему приложению. Доступны поставщики услуг, которые будут интегрированы с LDAP, AD и другими стандартами каталогов. ADFS (службы федерации Active Directory, ранее называвшаяся Geneva Server) - один из примеров, который связан с AD.
При правильной настройке свойства, связанные с удостоверением, такие как членство в группе, могут быть переданы вашему приложению как «утверждение», связанное с удостоверением - ваше приложение может делать с утверждением все, что угодно. Дело в том, что ваше приложение может узнать, к каким группам принадлежит пользователь, и другие свойства, например. адрес электронной почты, изучив утверждения, переданные в токене.
Федеративная аутентификация имеет двоякое преимущество. Во-первых, вы можете интегрироваться с любым каталогом, который вам нравится, а не только с LDAP, если есть провайдер (или, конечно, вы можете написать своего собственного).Во-вторых, он не допускает аутентификации в коде вашего приложения, поэтому вы можете изменить реализацию в будущем для поддержки различных сценариев.
Посетите http://msdn.microsoft.com/en-us/magazine/ee335707.aspx , чтобы познакомиться с Windows Identity Foundation (ранее под кодовым названием «Geneva Framework»). Или загляните в блог команды .
Я имею дело с некоторыми из тех же самых вещей, поэтому я собираюсь начать этот ответ с небольшого количества и, надеюсь, со временем дополню его.
Быстрый ответ: учитывая ваши требования, я собираюсь предложить вам изучить ДВА встроенных провайдера, которые Microsoft предоставляет вам: на основе SQL Server и на основе Active Directory. Из коробки, просто перевернув некоторую конфигурацию в вашем файле .config, вы можете переключиться с использования SQL Server на использование Active Directory. Если я не понимаю ваши потребности, может показаться, что это именно то, что вам нужно в ваших двух сценариях. Если вы сделаете это таким образом, 100% вашего приложения могут выглядеть и функционировать одинаково, даже с одной и той же кодовой базой. Перенос данных из существующего приложения одного развертывания в другое становится более интересным (и, к сожалению, у меня нет опыта в этом отношении), но чистое развертывание одного по сравнению с другим должно быть довольно простым.
Очевидно, что если вам не нравится поведение встроенных провайдеров, вы можете создать свой собственный.
Моя работа заключается в том, что мы использовали поставщика на основе SQL, и нам необходимо перейти на Active Directory, а встроенного поставщика может хватить, а может и не хватить для наших нужд (я все еще оцениваю это , и очень активно этим занимается на данный момент). Я также работал с некоторым контрольным кодом, так что в случае необходимости я уверен, что мы сможем достаточно хорошо создать нашего собственного провайдера.
Итак, я знаю, что это не совсем ответ на ваш вопрос (вопросы), но я надеюсь, что это дает вам повод подумать и помогает вам в некотором роде. Как я уже сказал, я рад добавить к этому больше по мере того, как сам углубляюсь в знания.