Руководство. Перенос приложений из Okta в Azure Active Directory

В этом руководстве вы узнаете, как перенести свои приложения из Okta в Azure Active Directory (Azure AD).

Создание данных инвентаризации текущих приложений Okta

Перед началом переноса следует задокументировать текущие параметры среды и приложений. Чтобы получить эти сведения из централизованного расположения, можно использовать API Okta. Для использования этого API необходим обозреватель API, например Postman.

Ниже приведен порядок действий при создании данных инвентаризации приложений.

  1. Установите приложение Postman. Затем создайте маркер API в консоли администрирования Okta.

  2. На панели мониторинга API в разделе Безопасность выберите Маркеры>Создать маркер.

    Screenshot that shows the button for creating a token.

  3. Введите имя маркера, а затем выберите Создать маркер.

    Screenshot that shows where to name the token.

  4. Запишите значение маркера и сохраните его. После нажатия кнопки Понятно оно будет недоступно.

    Screenshot that shows the Token Value box.

  5. В рабочей области в приложении Postman выберите Import (Импорт).

    Screenshot that shows the Import A P I.

  6. На странице Import (Импорт) выберите Link (Ссылка). Затем вставьте приведенную ниже ссылку, чтобы импортировать API: https://developer.okta.com/docs/api/postman/example.oktapreview.com.environment

    Screenshot that shows the link to import.

    Примечание

    Не изменяйте ссылку значениями своего арендатора.

  7. Чтобы продолжить, щелкните Import (Импортировать).

    Screenshot that shows the next Import page.

  8. После импорта API измените значение параметра Environment (Среда) на {ваш_домен_Okta} .

    Screenshot that shows how to change the environment.

  9. Измените среду Okta, щелкнув значок глаза. Затем выберите Изменить.

    Screenshot that shows how to edit the Okta environment.

  10. Обновите значения URL-адреса и ключа API в полях Initial Value (Начальное значение) и Current Value (Текущее значение). Измените имя в соответствии со своей средой. Затем сохраните значения.

    Screenshot that shows how to update values for the A P I.

  11. Загрузите API в Postman.

  12. Выберите Apps (Приложения) >Get List Apps (Получить список приложений) >Send (Отправить).

    Теперь можно распечатать все приложения в вашем арендаторе Okta. Список формируется в формате JSON.

    Screenshot that shows a list of applications in the Okta tenant.

Рекомендуется скопировать и преобразовать этот список JSON в формат CSV. Можно использовать общедоступный преобразователь, например Konklone. Кроме того, в PowerShell можно использовать командлеты ConvertFrom-Json и ConvertTo-CSV.

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

Перенос приложения SAML в Azure AD

Чтобы перенести приложение SAML 2.0 в Azure AD, сначала настройте это приложение в арендаторе Azure AD, чтобы обеспечить доступ к этому приложению. В данном примере мы преобразуем экземпляр Salesforce. Чтобы настроить приложения, следуйте инструкциям в этом руководстве.

Чтобы завершить перенос, повторите действия по настройке для всех приложений, обнаруженных в арендаторе Okta.

  1. На портале Azure AD выберите Azure Active Directory>Корпоративные приложения>Новое приложение.

    Screenshot that shows a list of new applications.

  2. В разделе коллекции Azure AD найдите Salesforce, выберите это приложение и щелкните Создать.

    Screenshot that shows the Salesforce application in Azure A D Gallery.

  3. После создания приложения на вкладке Единый вход выберите SAML.

    Screenshot that shows the SAML application.

  4. Скачайте сертификат (необработанный) и XML-файл метаданных федерации, чтобы импортировать их в Salesforce.

    Screenshot that shows where to download federation metadata.

  5. В консоли администрирования Salesforce выберите Identity (Удостоверение) >Single Sign-On Settings (Параметры единого входа) >New from Metadata File (Создать из файла метаданных).

    Screenshot that shows the Salesforce admin console.

  6. Передайте XML-файл, скачанный с портала Azure AD. Щелкните Создать.

    Screenshot that shows where to upload the XML file.

  7. Передайте сертификат, скачанный из Azure. Затем нажмите кнопку Save (Сохранить), чтобы создать поставщик SAML в Salesforce.

    Screenshot that shows how to create the SAML provider in Salesforce.

  8. Запишите значения в приведенных ниже полях. Эти значения будут использованы в Azure.

    • идентификатор сущности;
    • Login URL (URL-адрес для входа)
    • URL-адрес выхода.

    Затем выберите Download Metadata (Скачать метаданные).

    Screenshot that shows the values you should record for use in Azure.

  9. На странице Корпоративные приложения Azure AD в параметрах единого входа SAML выберите Отправить файл метаданных, чтобы передать файл на портал Azure AD. Перед сохранением убедитесь, что импортированные значения соответствуют записанным значениям.

    Screenshot that shows how to upload the metadata file in Azure A D.

  10. В консоли администрирования Salesforce выберите Company Settings (Параметры организации) >My Domain (Мой домен). Перейдите на страницу Authentication Configuration (Конфигурация проверки подлинности) щелкните Edit (Изменить).

    Screenshot that shows how to edit company settings.

  11. Для параметра входа выберите новый поставщик SAML, настроенный вами ранее. Затем нажмите кнопку Save (Сохранить).

    Screenshot that shows where to save the SAML provider option.

  12. В Azure AD на странице Корпоративные приложения выберите Пользователи и группы. Затем добавьте тестовых пользователей.

    Screenshot that shows added test users.

  13. Чтобы проверить конфигурацию, войдите в систему как один из тестовых пользователей. Перейдите в свою коллекцию приложений Майкрософт и выберите Salesforce.

    Screenshot that shows how to open Salesforce from the app gallery.

  14. Выберите только что настроенный поставщик удостоверений (IdP) для входа.

    Screenshot that shows where to sign in.

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

  15. На странице Корпоративные приложения назначьте оставшимся пользователям приложение Salesforce с соответствующими ролями.

    Примечание

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

  16. В консоли администрирования Salesforce выберите Company Settings (Параметры организации) >My Domain (Мой домен).

  17. На странице Authentication Configuration (Конфигурация проверки подлинности) щелкните Edit (Изменить). Отмените выбор Okta в качестве службы проверки подлинности.

    Screenshot that shows where to clear the selection for Okta as an authentication service.

Теперь приложение Salesforce успешно настроено для единого входа с помощью Azure AD.

Перенос приложения OIDC или OAuth 2.0 в Azure AD

Чтобы перенести приложение OpenID Connect (OIDC) или приложение OAuth 2.0 в Azure AD, сначала настройте это приложение для доступа в своем арендаторе Azure AD. В этом примере мы преобразуем пользовательское приложение OIDC.

Чтобы выполнить перенос, повторите приведенные действия по настройке для всех приложений, обнаруженных в арендаторе Okta.

  1. На портале Azure AD выберите Azure Active Directory>Корпоративные приложения. В меню Все приложения щелкните Новое приложение.

  2. Выберите Создать собственное приложение. В открывшемся меню введите имя приложения OIDC и выберите Регистрация разрабатываемого вами приложения для его интеграции с Azure AD. Щелкните Создать.

    Screenshot that shows how to create an O I D C application.

  3. На следующей странице настройте параметры арендатора для регистрации приложения. Дополнительные сведения см. в этой статье.

    В этом примере мы выберем Учетные записи в любом каталоге организации (любой каталог Azure AD — мультитенантный)>Зарегистрировать.

    Screenshot that shows how to select Azure A D directory multitenant.

  4. На странице Регистрация приложений в разделе Azure Active Directory откройте только что созданную регистрацию.

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

  5. На странице Обзор запишите значение Идентификатор приложения (клиента) . Этот идентификатор будет использоваться в вашем приложении.

    Screenshot that shows the application client I D.

  6. Выберите Сертификаты и секреты в области слева. Затем выберите Создать секрет клиента. Укажите имя секрета клиента и задайте срок его действия.

    Screenshot that shows the new client secret.

  7. Запишите значение и идентификатор секрета.

    Примечание

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

  8. В области слева выберите Разрешения API. Затем предоставьте приложению доступ к стеку OIDC.

  9. Выберите Добавить разрешение>Microsoft Graph>Делегированные разрешения.

  10. В разделе Разрешения OpenID выберите разрешения email, openid и profile. Нажмите кнопку Добавить разрешения.

    Screenshot that shows where to add Open I D permissions.

  11. Чтобы улучшить взаимодействие с пользователем и убрать запросы согласия пользователя, выберите Grant admin consent for Tenant Domain Name (Предоставить согласие администратора для доменного имени арендатора). Затем подождите, пока не отобразится состояние Разрешено.

    Screenshot that shows where to grant admin consent.

  12. Если у приложения есть URI перенаправления, введите соответствующий URI. Если для URL-адреса ответа используется вкладка Проверка подлинности, а затем — Добавить платформу и Веб, введите соответствующий URL-адрес. Выберите Маркеры доступа и Токены ИД. Затем выберите Настроить.

    Screenshot that shows how to configure tokens.

    В меню Проверка подлинности выберите Доп. параметры > Разрешить потоки общедоступных клиентов и, при необходимости, выберите Да.

    Screenshot that shows how to allow public client flows.

  13. Перед тестированием в приложении, настроенном для OIDC, импортируйте идентификатор приложения и секрет клиента. Выполните описанные выше действия, чтобы настроить для своего приложения такие параметры, как идентификатор клиента, секрет и области.

Перенос пользовательского сервера авторизации в Azure AD

Серверы авторизации Okta однозначно сопоставляются с регистрациями приложений, которые предоставляют API.

Сервер авторизации Okta по умолчанию должен быть сопоставлен с областями или разрешениями Microsoft Graph.

Screenshot that shows the default Okta authorization.

Дальнейшие действия