Active Directory и SSO - кто-нибудь с этим?

Question

Мы хотим внедрить функциональность единого входа в нашей организации, но мы не совсем уверены, какие у нас есть варианты, и какие могут быть преимущества / недостатки для разных решений.

-У нас есть несколько старых сайтов ASP (Active Server Pages), которые должны использовать SSO
-У нас есть несколько веб-приложений ASP.net, которые должны использовать SSO
Мы хотим, чтобы Sharepoint использовал SSO -CRM (Biztalk?) Интеграция (дополнительная информация о пользователе, такая как адрес, компания и т. Д.)

Поскольку мы в основном ориентированы на .net, c # и ориентированы на Microsoft, моей первой идеей было использование Active Directory.
Я также заметил, что есть что-то, называемое ADAM (режим приложения Active Directory) и ADFS (службы федерации Active Directory), но я не могу сказать, что понимаю, когда и где их следует использовать.

Вот краткий обзор различных веб-приложений
- «Моя личная страница»: пользователь входит в приложение, где он может изменять свои личные данные, а также информацию о своей компании и своих сотрудниках. (Asp.Net)
Приложение электронного обучения (ASP)
-CMS система для веб-публикации (ASP.Net)
-Sharepoint сайты

Мне не удалось найти ни одной статьи, в которой можно было бы сказать, что «AD - отличный выбор! Вы можете использовать его везде», поэтому, если у кого-то есть какой-либо опыт / отзывы, чтобы сообщить мне об этом, он бы быть действительно полезным.

Также: как должны управляться права / роли? Должны ли все права доступа / роли / роли для каждого приложения храниться в AD или они должны храниться в самих приложениях.

IE: AD хранит роли:
«Cms» <- разрешено входить в систему cms <br> "Cms.Article.AddAllowed" <- разрешено добавить статью <br> "Cms.Article.DeleteAllowed" <- разрешено удалить статью </p>

Или эту информацию следует разделить, чтобы AD содержала информацию о том, в какие приложения пользователю разрешено входить, а само приложение содержит информацию о том, что пользователю разрешено делать в приложении при входе в систему

AD права: "Cms" <- Разрешено входить в систему cms </p>

Cms права:
"Article.AddAllowed" <- разрешено добавить статью <br> "Article.DeleteAllowed" <- разрешено удалить статью </p>

Итак, когда пользователь входит в систему, он сначала проходит аутентификацию в AD, и если все идет хорошо, права для приложения Cms выбираются из таблицы прав в системе cms?

Какие у меня варианты? Какие еще решения кроме AD у меня есть?

Спасибо за любой отзыв, его очень ценят!

Answer 1

Мы сделали нечто подобное в моей организации. Вот общий поток:

• Пользователь запрашивает веб-страницу
• Пользователь перенаправляется на экран входа в систему вместе с запросом SAML
• Пользователь аутентифицируется в Active Directory
• Пользователь возвращается на веб-страницу запроса с ответом SAML
• Информация о группе / правах пользователя извлекается из базы данных
• Если пользователь запрашивает страницу с другого веб-сайта, происходит такой же процесс, однако, если пользователь все еще имеет сеанс или выбрал функцию «запомнить меня», то у пользователя нет аутентификации, и он входит в систему напрямую.

Мы используем Sharepoint, но еще не настроили SSO. Я считаю, что Sharepoint получает права пользователя от своей собственной базы данных / системы. У нас также есть собственная система обновления групп / прав пользователей. Я знаю, что Sharepoint может использовать веб-сервисы, чтобы вы могли обновлять Sharepoint при использовании централизованной системы управления пользователями (конечно, вам придется ее создать). Главное - узнать, откуда Sharepoint получает информацию о пользователе и как вы можете привязать к ней существующую систему ...

Я бы не стал полагаться на Active Directory для хранения информации о группе / правах. Это боль в сравнении с базой данных и не гибкая. Это нормально для аутентификации и управления паролями, вам просто нужно привязать пользователя в Active Directory к вашей системе базы данных.

Answer 2

Насколько я знаю, Active Directory полезна только для пользователей вашего домена. Вам потребуется администратор для управления всеми этими пользователями и добавления новых пользователей.

Я сам работал над проектом, в котором я хотел, чтобы пользователи входили в систему, просто чтобы узнать их личность. Я даже не заботился об их правах доступа, а просто хотел, чтобы у каждого посетителя была личность, что-то более надежное, чем IP-адрес, cookie, сеансовый ключ или что-то еще. Поэтому я сначала спросил у моих администраторов, могу ли я использовать Active Directory для этого проекта. Конечно, я мог. Но веб-хост не был связан с доменом нашей компании, поэтому у меня был только один пользователь. Да, мой администратор иногда немного саркастичен.

Итак, я начал изучать варианты единого входа. OpenID, как этот сайт, является хорошим вариантом, и вы могли бы даже реализовать свой собственный сервер OpenID и потребовать, чтобы все посетители сначала зарегистрировались там. Это очень мощная техника, и вы меньше беспокоитесь об управлении пользователями в вашем проекте. (Потому что об этом позаботится провайдер OpenID.)

Однако вместо этого я использовал CardSpace. :-) С помощью CardSpace каждый пользователь может создать свой собственный токен и сохранить его в своей системе. Чтобы войти, веб-сайт просто запрашивает карту, а пользователь просто нажимает на нее. Эти карты могут быть перенесены в другие системы, но чаще всего они привязаны к одному компьютеру и пользователю. (Хотя пользователи могут делиться картой!)

Права и роли отличаются от аутентификации. Люди всегда думают, что они связаны, хотя в действительности это разные вещи. Во-первых, используйте OpenID или CardSpace или другой метод аутентификации для проверки личности пользователя. Неважно, как они идентифицированы, вам просто нужен идентификатор. Далее вам нужны права и роли. Роли - это в основном просто группы пользователей, и вы можете связать личность с группой. Или для нескольких групп. И права будут связаны с ролями, а не с пользователями. Но то, как вы собираетесь разделить эти роли, зависит только от приложений. Просто помните, что кто-то, кто является администратором в вашей системе контроля версий, не должен быть администратором в вашей базе данных клиентов. Роли, как правило, определяются приложением, поэтому каждое приложение может управлять своими собственными правами и ролями, и им просто нужен способ связать их с личностью.

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