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

Question

Резюме

Короче говоря, нам было поручено потрясти части аутентификации и авторизации довольно старого и раздутого приложения 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 управления ролями, или мы должны продолжать катиться самостоятельно? Я знаю, что это решение будет зависеть от наших требований, поэтому я перейду к ним ниже

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

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

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

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

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

Answer 1

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

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

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

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

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

1. Может связывать ваши роли с группами AD (или группами Windows)
2. Его можно сохранить в виде файла, чтобы вы могли сохранить его вместе с приложением.
3. Приятно разбивает авторизацию на задачи, операции и роли.
4. Поставляется с отдельным административным инструментом
5. Версия 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 действительно продвигает это решение, которое обещает единый вход, если вы можете заставить его работать. Уловка этого решения заключается в его настройке, особенно между вами и партнером.

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

FYI материал

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

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

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

Примечания

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

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

Answer 5

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

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

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

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

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