Подключите Azure Active Directory к локальной клиентской AD

Подключите Azure Active Directory к локальной клиентской AD

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

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

Большинство, если не все наши клиенты будут иметь локальный Active Directory, и было бы идеально, если бы мы могли как-то использовать его с нашим приложением. Подключение нашего веб-приложения к локальному AD на самом деле не вариант, потому что системные администраторы (по понятным причинам) не дадут нам к нему доступ.

Мы также можем настроить AD в Azure. Поэтому я подумал, что, возможно, мы могли бы синхронизироваться из локального AD с нашим AD в Azure, а затем использовать его оттуда. Однако при тестировании инструмента Microsoft Azure Active Directory Connect он запросил у меня учетную запись администратора для нашей среды Azure. Очевидно, что мы не хотим предоставлять нашим клиентам доступ к нашему порталу Azure, поэтому, похоже, это не сработает.

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

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

решение1

ADConnect — это способ синхронизации локального каталога с вашим облаком. Он запрашивает имя пользователя и пароль для настройки начальной синхронизации и внесения изменений в синхронизацию, если вы снова входите в систему с помощью инструмента. Вам также понадобится учетная запись DA для локального администратора, пока вы настраиваете его. Если у вас нет ни одной из этих учетных записей, ни одной из них, вы не сможете завершить настройку.

Исходя из того, что вы предлагаете, Azure B2C — это то, что вы хотите настроить. В противном случае настройте федерацию ADFS между вашими доменами и доменами клиентов, чтобы вам не пришлось возиться с запросами имени пользователя/пароля. Я предполагаю, что ваши приложения поддерживают утверждения и у вас есть собственный Windows AD, чтобы настроить ADFS.

Если вы пытаетесь настроить тестовую среду ADFS, я следовал инструкциям блога из 4 частей, чтобы создать свою первую лабораторную работу — надеюсь, она подойдет и вам.

http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-adfs-lab-on-server-2012-part-1.aspx http://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-adfs-lab-on-server-2012-part2-web-sso.aspx

решение2

Если вы настроите приложение для поддержки аутентификации SAML, то клиент может настроить свои ADFS (или другие) для работы с их AD. Обычно это делается для SSO для сторонних приложений.

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

На своей стороне вы можете создать собственного поставщика удостоверений, использовать сторонний сервис или развернуть сервер федерации, такой как ADFS. Но есть и другие (как коммерческие, так и с открытым исходным кодом), такие как PingFederate и Shibboleth. Там буквально сотни вариантов. Если вам нужен SDK - Ping Identity (разработчики PingFederate) предлагают его для нескольких языков (Java, C# и т. д.). Я уверен, что есть также SDK с открытым исходным кодом, которые помогут с этим.

Идентификация — сложная тема. Чем больше вы сможете передать эту задачу специализированной компании или команде, тем лучше для вас (Azure B2C находится в стадии предварительной версии, как указано в других ответах, но если вы хотите ускорить процесс, рассмотрите сторонние решения).

Связанный контент