Создание приложений в экосистеме идентификатора Microsoft Entra

При создании приложений на идентификаторе Microsoft Entra сначала необходимо установить удостоверение для приложения. Приложению требуется идентификатор в Microsoft Entra ID для запроса токенов. Интерфейс программирования приложений (API) должен иметь идентификацию в Microsoft Entra ID, чтобы токены были выданы для приложений для доступа к ресурсам.

Из этой статьи вы узнаете, как зарегистрировать приложения в клиенте Идентификатора Microsoft Entra в Центре администрирования Microsoft Entra или с помощью API Microsoft Graph. Это второй в серии статей о том, как независимые разработчики программного обеспечения (ISV) могут создавать и оптимизировать свои приложения для Идентификатора Microsoft Entra. В этой серии вы можете узнать больше о следующих разделах:

Регистрация приложений

Разработчики могут регистрировать приложения в качестве мультитенантных приложений и однотенантных приложений. Мы рекомендуем использовать мультитенантные приложения поставщикам независимого программного обеспечения (ISV). Мультитенантное приложение имеет одну регистрацию приложения, которой полностью управляет и регистрируется в своем арендаторе поставщик программного обеспечения. Узнайте, как создать арендатора Microsoft Entra ID для регистрации вашего приложения.

Чтобы предоставить решения любому клиенту, использующему Microsoft Entra ID, и обеспечить беспроблемное подключение к его клиенту Microsoft Entra ID, перейдите в центр администрирования Microsoft Entra, регистрация приложений, зарегистрируйте приложение. В этой новой регистрации приложения выберите поддерживаемые типы учетных записей, учетные записи в любом каталоге организации (любой клиент Microsoft Entra ID-Multitenant) или учетные записи в любом каталоге организации (любой клиент Microsoft Entra ID-Multitenant) и личные учетные записи Майкрософт (например, Skype, Xbox).

Снимок экрана: параметры конфигурации приложения в Центре администрирования Microsoft Entra.

Подключение мультитенантного приложения к внешнему клиенту может быть таким же простым, как запуск приложения и вход пользователя в приложение. Когда арендатор разрешает согласие пользователя (пользователи могут входить в приложения без предварительного утверждения приложения администратором), интеграция приложения требует только, чтобы пользователь вошел в приложение. В этом семинаре по идентификации личности для разработчиков (код времени 1:05:20–1:08:00) демонстрируется добавление приложения в учетную запись клиента, когда пользователь заходит в приложение.

При регистрации приложения в клиенте Идентификатора Microsoft Entra он получает идентификатор приложения (идентификатор приложения), который также называется идентификатором клиента для приложения. Он похож на userid пользователя, который однозначно идентифицирует приложение. Идентификатор приложения является глобально уникальным в облаке Идентификатора Microsoft Entra ИД и неизменяемым. Все взаимодействия между приложением и идентификатором Microsoft Entra включают идентификатор приложения.

В дополнение к идентификатору приложения регистрация приложения содержит сведения о приложении, которое разработчики приложений знают или должны знать. Например, разработчику приложений необходимо знать идентификатор приложения для взаимодействия с идентификатором Microsoft Entra. Разработчик знает тип приложения, который они строят (веб-приложение, собственное приложение, одностраничное приложение, мобильное приложение или классическое приложение). Типы приложений имеют обязательные атрибуты.

Например, обязательный атрибут приложения — это универсальный идентификатор ресурса перенаправления (URI). Атрибут сообщает Microsoft Entra ID, какой веб-адрес или адрес нативного приложения отправить пользователю после проверки подлинности или авторизации. Разработчик знает URI перенаправления для приложения на основе типа приложения и расположения приложения.

Манифест приложения (доступ к которому выполняется из Центра администрирования Microsoft Entra или с ПОМОЩЬЮ API Microsoft Graph), хранит множество атрибутов приложения. Ознакомьтесь с манифестом приложения Microsoft Entra, чтобы узнать о атрибутах приложения и их допустимых значениях.

Образцы кода для аутентификации и авторизации на платформе удостоверений Microsoft служат для ознакомления с рекомендуемыми настройками для разрабатываемых вами приложений. Найдите пример приложения, который похож на приложение, которое вы создаете, и ознакомьтесь с документацией. Примеры подробно описывают необходимые настройки регистрации приложений в зависимости от типа приложения. Например, если вы создаете API в Node.js, вы можете найти примеры, которые приводят к этим инструкциям по регистрации.

Регистрация приложения сообщает, что знает разработчик. В каждом арендаторе, из которого пользователи могут аутентифицироваться в вашем мультитенантном приложении, администраторы арендаторов настраивают запуск приложений в своём арендаторе. Например, администратор клиента может задать политику условного доступа, которая ограничивает приложение определенным сетевым расположениям. Кроме того, политика условного доступа может требовать многофакторной проверки подлинности (MFA) для доступа пользователя к приложению или параметрам приложения, которые позволяют определенным пользователям или группам использовать приложение.

Чтобы включить такие ограничения, администраторы клиентов нуждаются в контрольных точках для приложений в клиенте. Идентификатор Microsoft Entra автоматически создает корпоративное приложение в каждом клиенте, в котором пользователь проходит проверку подлинности приложения. В Центре администрирования Microsoft Entra они называются корпоративными приложениями, но объекты являются субъектами-службами. Узнайте больше о приложениях и основных службах в Microsoft Entra ID.

После проверки подлинности приложения Microsoft Entra ID создает учетную запись службы в клиенте, из которого пользователь прошел проверку подлинности. Администраторы клиента могут использовать объект субъекта-службы в Microsoft Graph (или в Центре администрирования Microsoft Entra, Корпоративные приложения) для настройки работы приложения в клиенте.

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

Хотя мы рекомендуем мультитенантные приложения для регистрации приложений для поставщиков программного обеспечения, одно клиентское приложение является еще одним вариантом регистрации приложений. Вместо единственной регистрации приложения в клиенте независимого поставщика программного обеспечения, где ISV полностью управляет регистрацией, вы можете попросить своих клиентов зарегистрировать ваше приложение в их клиенте для использования вашего приложения. После завершения регистрации клиент настраивает экземпляр вашего приложения с данными их регистрации приложения. Мы рекомендуем использовать этот подход к приложению одного клиента в первую очередь для приложений Line of Business, разработанных для конкретных предприятий.

Из-за накладных расходов на регистрацию и настройку вашего приложения клиентами, мы не рекомендуем использовать однопользовательские приложения для ISV. Однако существуют сценарии, для которых мультитенантное приложение невозможно для вашего приложения.

Если приложение использует язык разметки утверждения безопасности 2.0 (SAML), а не OpenID Connect (OIDC) или OAuth 2.0, он следует одной модели регистрации приложений клиента. Для приложений SAML порядок создания основных служб и регистрации приложений отличается от порядка, используемого для приложений OIDC или OAuth 2.0, по крайней мере для администратора, добавляющего приложение SAML в клиента. Вместо регистрации приложения и автоматического создания служебного принципала Microsoft Entra ID администраторы начинают с создания корпоративного приложения. Идентификатор Microsoft Entra автоматически создает регистрацию приложения. Коллекция приложений Microsoft Entra ID, описанная в разделе "Публикация приложений ", упрощает процесс создания приложения SAML для администраторов.

Ограничения на универсальные идентификаторы ресурсов перенаправления (URI) могут препятствовать созданию мультитенантного приложения поставщиком программного обеспечения. Приложение может иметь не более 256 URI перенаправления без подстановочных знаков. Если приложению требуется уникальный URI перенаправления для каждого клиента, и для каждого клиента требуется более 256 клиентов, требующих уникального экземпляра, возможно, не удается создать мультитенантное приложение. По соображениям безопасности нельзя использовать подстановочные знаки (*) в URI-адресах перенаправления Microsoft Entra ID. Один из вариантов — иметь один URI перенаправления для центральной службы (если это возможно). Центральный URI перенаправления будет проверять токен, а затем перенаправлять пользователя на конечную точку клиента.

Публикация приложений

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

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

  • Опубликуйте приложение из проверенного домена. Домен издателя информирует пользователей и администраторов о том, какие местоположения получают их данные. Публикация из проверенного домена издателя показывает, что зарегистрированный клиент приложения имеет контроль над доменом, перечисленным в качестве издателя приложения.
  • Публикуйте свое приложение с использованием проверки издателя. Наличие проверенного домена издателя является обязательным условием для проверки издателя, что выходит за рамки простого отображения того, что издатель приложения имеет контроль над доменом. Проверка издателя показывает, что корпорация Майкрософт подтвердила подлинность юридического лица, стоящего за доменом и арендатором. Пользователи, не являющиеся администраторами, часто не доверяют мультитенантным приложениям от непроверенных поставщиков. Администраторы могут настроить арендаторы таким образом, чтобы приложения, не полученные от проверенных издателей, всегда требовали согласия администратора. Проверка издателя в основном предназначена для поставщиков программного обеспечения, которые создают мультитенантные приложения на платформе OAuth 2.0 и OIDC. Проверенные издатели являются членами Программы Microsoft Cloud Partner. Проверка издателя не влияет на однотенантные приложения, например приложения SAML или Line of Business.
  • Опубликуйте приложение в галерее приложений Идентификатора Microsoft Entra. Вы можете запросить у Microsoft добавить ваши приложения, использующие SAML 2.0, а также приложения, использующие OAuth 2.0 и OIDC, в галерею приложений Microsoft Entra ID. Администраторы находят предварительно интегрированные приложения в галерее приложений Microsoft Entra ID из Центра администрирования Microsoft Entra, Корпоративные приложения, Новые приложения. Публикация приложения в коллекции приложений Идентификатора Microsoft Entra упрощает и сводит к минимуму конфигурацию для приложения. Корпорация Майкрософт тестирует приложения и обеспечивает проверку совместимости, особенно ценную для приложений с помощью SAML 2.0, требующих настройки перед использованием. Вы можете использовать реализацию 2.0 системы приложения управления удостоверениями между доменами (SCIM), чтобы настроить приложение вашей галереи приложений для предоставления. См. раздел "Автоматическое предоставление". Чтобы приступить к работе, отправьте запрос на публикацию приложения. Вы можете обеспечить единый вход и автоматическое создание учетных записей с помощью SCIM, используя одно приложение в каталоге приложений.
  • Участие в программе соответствия приложений Microsoft 365. Использование проверенного домена показывает, что у вас есть контроль над доменом. Проверка издателя показывает, что корпорация Майкрософт проверила вашу организацию как аутентичную. Размещение вашего приложения в галерее приложений Microsoft Entra ID показывает, что оно работает с Microsoft Entra ID для упрощённой интеграции. Программа соответствия требованиям Microsoft 365 позволяет вам информировать ваших клиентов о безопасности и соответствии вашего приложения через аттестацию издателя, сертификацию Microsoft 365 или используя средство автоматизации соответствия приложений (ACAT) в Azure. В нем показано, как приложение защищает ресурсы, которым клиент авторизует доступ к приложению.

Автоматическое обеспечение

Управление предоставлением приложений в Microsoft Entra ID может автоматически настраивать учетные записи пользователей, объекты групп и роли для облачных приложений, к которым пользователи должны иметь доступ. В дополнение к созданию объектов пользователей и групп, автоматическая подготовка учетных данных включает поддержание и удаление удостоверений пользователей при изменении статуса или ролей. Служба подготовки Microsoft Entra автоматически подготавливает пользователей и группы к приложениям, вызывая конечную точку API управления объектами SCIM, которую предоставляет приложение.

Для НПО преимущества предоставления приложений в Microsoft Entra ID включают следующее.

  • Подготовка приложения с помощью Microsoft Graph возможна, создание конечной точки SCIM позволяет подготовиться к работе с поставщиками удостоверений (idPs), поддерживающими SCIM. Большинство поставщиков удостоверений личности поддерживают протокол управления SCIM.
  • Предоставление — это операция синхронизации, где данные синхронизируются между Microsoft Entra ID и приложением. Для реализации решения синхронизации на основе Microsoft Graph приложение требует доступа ко всем атрибутам всех пользователей и групп в клиенте. Некоторые клиенты идентификатора Microsoft Entra неохотно разрешают такой широкий доступ. С помощью SCIM администратор может выбрать атрибуты для синхронизации, которые Microsoft Entra ID синхронизирует с приложением. Многие администраторы предпочитают иметь этот точный элемент управления, доступный только с реализацией SCIM.
  • Создание собственной службы синхронизации Microsoft Graph для провижнинга означает, что необходимо управлять этой службой и реализовывать pull-модель для мониторинга Microsoft Entra ID на изменения. При внедрении конечной точки SCIM Microsoft Entra ID управляет службой подготовки и применяет изменения в вашем приложении.

Используйте SCIM, Microsoft Graph и Microsoft Entra ID для предоставления пользователям доступа и обогащения приложений данными с руководством о том, когда следует использовать SCIM, а когда - Microsoft Graph. Используйте документацию Microsoft для планирования, построения и проверки вашего SCIM-эндпоинта с помощью Microsoft Entra ID, а также для устранения известных проблем с соответствием SCIM.

Помимо синхронизации данных с приложениями, идентификатор Microsoft Entra предлагает подготовку с помощью облачных приложений для управления персоналом (HR). Подготовка на основе кадров — это процесс создания цифровых удостоверений на основе решения для кадров. Системы управления персоналом становятся точкой авторизации для этих вновь созданных цифровых удостоверений и часто являются отправной точкой для многочисленных процессов предоставления. Локальные решения по управлению персоналом могут использовать Microsoft Identity Manager для предоставления пользователей к локальной службе Active Directory. Затем они могут синхронизироваться с идентификатором Microsoft Entra, используя Microsoft Entra Connect, или напрямую с идентификатором Microsoft Entra.

Благодаря подготовке, управляемой API, облачные ИСВ кадров могут предоставлять родные функции синхронизации, чтобы изменения в системе кадров автоматически втекали в Microsoft Entra ID и подключенные локальные домены Active Directory. Например, приложение для управления кадрами или приложение для информационных систем учащихся может отправлять данные в Microsoft Entra ID сразу после завершения транзакции или в рамках массового обновления в конце дня. Чтобы начать, изучите концепции входящей подготовки, управляемой API, исследуйте функцию bulkUpload в Microsoft Graph и более подробно ознакомьтесь с концепциями, сценариями и ограничениями подготовки, управляемой API.

Следующие шаги

  • Last updated on