Внешнее удостоверение Azure AD с использованием SAML без приглашения

avatar
user3731783
1 июля 2021 в 21:26
995
1
2

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

Однако при чтении этой статьи создается впечатление, что интеграция SAML основана на приглашении.

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

Вот мои потребности:

  1. После добавления внешнего idp пользователи должны иметь возможность входить в систему, используя свои собственные учетные данные через свой idp. Для использования приложения дополнительная информация не требуется.
  2. Я должен предоставить им доступ к пользовательским приложениям (обязательно) и ресурсам Azure (необязательно)
  3. Выберите, какие IDP разрешены для каждого приложения? (если возможно)

Заранее спасибо.

Источник

Ответы (1)

avatar
AnsumanBal-MT
6 июля 2021 в 15:30
3

Вопрос 1: После добавления внешнего idp пользователи должны иметь возможность входить в систему, используя свои собственные учетные данные через свой idp. Для использования приложения дополнительная информация не требуется.

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

Использование общей конечной точки: Гостевые пользователи теперь могут входить в мультитенантные приложения или сторонние приложения Майкрософт через общую конечную точку (URL), например https:// myapps.microsoft.com. Раньше общий URL-адрес перенаправлял гостевого пользователя на его домашний клиент, а не на ваш ресурсный клиент для проверки подлинности, поэтому требовалась ссылка для конкретного клиента (например, https://myapps.microsoft.com/?tenantid=). Теперь гостевой пользователь может перейти по общему URL-адресу приложения, выбрать параметры входа, а затем выбрать Войти в организацию. Затем пользователь вводит название вашей организации.

Использование прямой ссылки: В качестве альтернативы электронному приглашению или общему URL-адресу приложения вы можете дать гостю прямую ссылку на ваше приложение или портал. Сначала вам нужно добавить гостевого пользователя в свой каталог через Azure Portal или Powershell. Затем вы можете использовать любой из настраиваемых способов развертывания приложений для пользователей, включая прямые ссылки для входа. Когда гость использует прямую ссылку вместо электронного приглашения, он по-прежнему будет получать согласие в первый раз.

Ссылка:

Добавление гостей B2B без ссылки с приглашением или сообщения электронной почты — Azure AD

Использование приглашения в совместной работе B2B — Azure AD

Вопрос 2 : Я должен предоставить им доступ к пользовательским приложениям (обязательно) и ресурсам Azure (необязательно)

Ответ: Добавьте пользователей в качестве гостей в Azure Active Directory, но по умолчанию им будет отправлено приглашение, даже если они не откроют его. Вы можете назначить приложение в своем корпоративном приложении для их использования .

Большинство федеративных приложений, поддерживающих подключение SAML 2.0, WS-Federation или OpenID, также поддерживают возможность для пользователей запускать приложение, а затем выполнять вход через Azure AD либо путем автоматического перенаправления, либо путем нажатия на ссылку для подписи. in. Это называется входом, инициированным поставщиком услуг, и большинство федеративных приложений в галерее приложений Azure AD

.

Ссылка:

Возможности приложений для конечных пользователей — Azure Active Directory

Краткое руководство. Добавление гостевых пользователей на портал Azure — Azure AD

Чтобы предоставить гостевому пользователю доступ к ресурсам Azure, вы можете вручную добавить роль пользователям.

Вопрос 3: Выберите, какие IDP разрешены для каждого приложения?

Ответ: Создайте разные потоки пользователей и добавьте нужных IDP в потоки пользователей, а затем назначьте приложения, зарегистрированные в Azure AD, потокам пользователей в зависимости от того, какие IDP необходимы для данного приложения.

Ссылка:

Добавление пользовательского потока самостоятельной регистрации — Azure AD

Вопрос 4: Я добавил Okta в качестве внешнего удостоверения с помощью SAML в Azure AD. Создал «Регистрацию приложения» как мультитенант. Но я получаю эту ошибку.

AADSTS50020: учетная запись пользователя "xxx" от поставщика удостоверений "http://www.okta.com/xxxxx" не существует в арендаторе и не может получить доступ к приложению "0000000c-0000-0000-c000-000000000000"( Панель доступа к приложениям Майкрософт) в этом арендаторе. Сначала необходимо добавить учетную запись в качестве внешнего пользователя в арендаторе. Выйдите и войдите снова, используя другую учетную запись пользователя Azure Active Directory.

Решение: Убедитесь, что пользователь добавлен в одну из групп администраторов партнеров, т. е. AdminAgents в клиенте-партнере.

Ссылка:

Управление доступом через аутентификацию для поставщиков облачных решений.

Вопрос 5: Действия по настройке самостоятельной регистрации для приложения.

Сценарий тестирования в моей лаборатории

  • Azure AD с приложением, зарегистрированным в колонке регистрации приложений.
  • Еще один арендатор AD с пользователями.

enter image description here

Шаг 1: В приведенных выше настройках совместной работы с внешними удостоверениями убедитесь, что enable guest user self service включен.

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

enter image description here

Шаг 2: Создайте поток пользователя, перейдя в колонку потока пользователя и создав новый поток.

enter image description here

enter image description here

Шаг 3: После создания потока пользователя щелкните поток пользователя, перейдите в колонку приложения и нажмите Добавить приложение.

enter image description here

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

enter image description here

Вывод:

После выполнения указанных выше настроек вы можете получить доступ к URL-адресу своего приложения. Укажите пользователя другого рекламного клиента, и вы получите вывод, как показано ниже. Нажмите «Создать новый».

enter image description here enter image description here

После того, как пользователь из другого арендатора AD примет его, он будет успешно зарегистрирован как гостевой пользователь в вашем арендаторе.

enter image description here

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

user3731783
6 июля 2021 в 20:51
0

Большое спасибо за подробный ответ. Я пробовал это. Я добавил Okta в качестве внешнего удостоверения с помощью SAML в Azure AD. Создал «Регистрацию приложения» как мультитенант. Но я получаю эту ошибку. AADSTS50020: User account 'xxx' from identity provider 'http://www.okta.com/xxxxx' does not exist in tenant '<my tenant>' and cannot access the application '0000000c-0000-0000-c000-000000000000'(Microsoft App Access Panel) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

user3731783
6 июля 2021 в 20:58
0

Я получаю сообщение об ошибке выше при доступе к myapps.microsoft.com/?tenantid=<mytenantid> или при прямом доступе к URL-адресу моего приложения или при создании приложения с помощью «Приложение не из галереи»

AnsumanBal-MT
7 июля 2021 в 03:57
1

@user3731783 user3731783, я добавил вышеуказанный запрос и решение как вопрос 4 в ответе..

user3731783
8 июля 2021 в 21:23
0

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

AnsumanBal-MT
9 июля 2021 в 05:16
0

Здравствуйте, @user3731783, для автоматизации процесса регистрации, если пользователь не является частью арендатора, мы можем использовать пользовательский процесс самостоятельной регистрации, который упоминается в вопросе 3, поскольку в нем упоминается: «Для приложений, которые вы создаете, вы можете создавать пользовательские потоки. которые позволяют пользователю зарегистрироваться в приложении и создать новую гостевую учетную запись».

user3731783
9 июля 2021 в 17:20
1

да, я так и думал. Но SAML idp, который я добавил, не отображается для выбора при добавлении нового пользовательского потока.

UserP
9 июля 2021 в 18:41
1

Я попытался создать поток с идентификатором SAML idp и столкнулся с той же проблемой. Я мог обнаружить, что в настоящее время мы не можем добавить какой-либо SAML idp в поток для самообслуживания, зарегистрировать только Microsoft и другие поддерживаемые idp, которые отображаются на странице. Итак, на данный момент нам нужно вручную добавить пользователей в качестве гостей. Я сослался на serverfault.com/questions/1062333/…

UserP
9 июля 2021 в 19:02
0

+1, если принять во внимание вышеизложенное, то @AnsumanBal-MT ваш ответ полезен. Спасибо за подробный ответ..

user3731783
9 июля 2021 в 19:31
1

Подводя итог, если мы хотим использовать что-либо, кроме Google, Facebook или поставщика по умолчанию (Azure AD, учетная запись Microsoft), мы должны добавить пользователей заранее. Надеемся, что Microsoft скоро добавит поддержку SAML idp для пользовательских потоков. Это очень ограничительно, учитывая, что Azure AD в основном используется предприятиями, и многие из них предпочитают поставщиков SAML по сравнению с Google/Facebook.

UserP
9 июля 2021 в 20:55
0

Я согласен с вашей точкой зрения @user3731783 , мы можем оставить отзыв о функции в azure active directory здесь feedback.azure.com/forums/169401-azure-active-directory.

user3731783
14 июля 2021 в 16:27
0

@ AnsumanBal-MT С каждым днем ​​это становится все более запутанным. Самообслуживание также не работает с другим арендатором Azure AD. Я попытался использовать URL-адрес myapps.microsoft.com?tenantid=<> и получил такое же сообщение, user does not exist in tenant. У меня нет общего URL-адреса для приложения, так как оно зарегистрировано с помощью блейда регистрации приложений. Любой совет?

AnsumanBal-MT
14 июля 2021 в 16:40
0

Здравствуйте, @user3731783, могу я узнать IDP, который вы сейчас используете?

user3731783
14 июля 2021 в 17:32
0

@AnsumanBal-MT В моем комментарии мое приложение использует одного арендатора Azure AD, а пользователь — другого арендатора Azure AD.

user3731783
14 июля 2021 в 19:11
0

@AnsumanBal-MT Чтобы подытожить и добавить дополнительный контекст, как уже упоминалось в вопросах, Azure AD является моим источником. Все приложения будут использовать AzureAD, и я хочу добавить в свой клиент других партнеров. Мы уже пришли к выводу, что учетные записи, принадлежащие внешним удостоверениям, добавленным через SAML, не будут работать без предварительного добавления этих учетных записей в Azure AD. Теперь я пытаюсь работать с пользователями в другой Azure AD, и это тоже не работает.

AnsumanBal-MT
15 июля 2021 в 08:00
0

Здравствуйте, @user3731783, я создал тестовую среду в соответствии с вашим сценарием и настроил самостоятельную регистрацию для пользователей в другом арендаторе, и у меня это сработало.. я добавил шаги для этого в ответ на вопрос 5.. Не могли бы вы попробуйте и вернитесь назад, если он работает ..

user3731783
15 июля 2021 в 18:12
0

@ AnsumanBal-MT Я очень ценю усилия, которые вы прикладываете к написанию подробных ответов, спасибо. Я попробовал это, и это сработало, я остановился, как только он сказал «Создать новую учетную запись». Однако есть несколько недоразумений: когда я создаю учетную запись на экране ввода пароля, на нем отображается фоновое изображение текущего арендатора (клиента приложения), а не bg-изображение моего фактического арендатора, которому принадлежит эта учетная запись. Кроме того, в сведениях о пользователе identityissuer также является арендатором приложения, что имеет смысл, но я нигде не вижу фактического арендатора внешнего пользователя.

AnsumanBal-MT
15 июля 2021 в 18:30
0

@ user3731783, приятно слышать, что теперь это работает. А что касается фонового изображения, оно покажет изображение клиента приложения, поскольку приложение зарегистрировано там, и мы подписываемся на гостевого пользователя клиента приложения. То же самое относится и к эмитенту удостоверений.