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

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

Порядок публикации приложения в коллекции приложений Azure AD следующий:

  1. Предварительные требования
  2. Выберите подходящий стандарт единого входа для своего приложения.
  3. Реализуйте единый вход в приложении.
  4. Реализация подготовки пользователей SCIM в приложении (необязательно)
  5. Создайте клиент Azure и протестируйте в нем приложение.
  6. Разработайте и опубликуйте документацию.
  7. Отправить запрос на публикацию приложения.
  8. Присоединитесь к программе Microsoft Partner Network.

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

Ниже перечислены некоторые преимущества добавления приложения в коллекцию Azure AD.

  • Клиенты будет доступен самый удобный способ единого входа в ваше приложение.
  • Конфигурация приложения будет простой и минимально необходимой.
  • Ваше приложение можно будет найти в коллекции с помощью быстрого поиска.
  • Эту интеграцию могут использовать все клиенты Azure AD категорий "Бесплатный", "Базовый" и "Премиум".
  • Нашим общим клиентам предлагается пошаговое руководство по настройке.
  • Клиенты, использующие SCIM (System for Cross-domain Identity Management ), смогут выполнять подготовку вашего приложения средствами этой же системы.

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

  • Единый вход для пользователей. С помощью единого входа вы сокращаете затраты на поддержку, упрощая процесс для своих клиентов. Если обеспечена возможность единого входа одним щелчком, ИТ-администраторам ваших клиентов не нужно будет учиться настраивать приложение для использования в своей организации. Дополнительные сведения о едином входе см. в статье Что собой представляет единый вход?
  • Приложение может быть обнаружено в коллекции приложений Microsoft 365, средстве запуска приложений Microsoft 365 и в Поиске (Майкрософт) на сайте Office.com.
  • Интегрированное управление приложениями. Дополнительные сведения об управлении приложениями в Azure AD см. в статье "Что такое управление приложениями?".
  • Приложение может использовать API Graph для доступа к данным, повышающим производительность работы пользователей в экосистеме Майкрософт.
  • Документация к конкретному приложению, созданная совместно с группой Azure AD для наших общих клиентов, упрощает внедрение.
  • Вы предоставляете своим клиентам возможность полностью управлять проверкой подлинности и авторизацией своих сотрудников и гостей.
  • Все обязанности по управлению учетными записями и обеспечению их соответствия возлагаются на клиента — владельца соответствующих удостоверений.
  • Предусмотрена возможность включать или отключать единый вход для конкретных поставщиков удостоверений, групп или пользователей в соответствии с потребностями их бизнеса.
  • Вы повышаете рыночную привлекательность своих продуктов и облегчаете их внедрение. Многие крупные организации требуют или стремятся к тому, чтобы им сотрудникам был обеспечен простой единый вход во все приложения. Очень важно, чтобы единым входом было легко пользоваться.
  • Вы снижаете барьеры для конечных пользователей, что может повысить популярность вашего приложения среди них и ваш доход.
  • Клиенты, использующие SCIM (System for Cross-domain Identity Management ), смогут выполнять подготовку вашего приложения средствами этой же системы.
  • Единый вход пользователей в приложения с помощью Azure AD избавляет от необходимости использовать отдельные наборы учетных данных и повышает уровень безопасности и удобства.

Совет

Предлагая свое приложение для использования другим компаниям посредством единовременной покупки или подписки, вы делаете его доступным для клиентов в их средах Azure. Это называется созданием многоклиентского приложения. Общие сведения об этой концепции см. в статье Аренда в Azure Active Directory.

Предварительные требования

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

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

  • Федеративные приложения (Open ID и SAML/WS-Fed) должны поддерживать модель "программное обеспечение как услуга" (SaaS), чтобы попасть в коллекцию Azure AD. Приложения из корпоративной коллекции должны поддерживать множество конфигураций клиентов, а не какую-то одну конкретную конфигурацию.
  • Для поддержки Open ID Connect приложение должно быть многоклиентским, и для него должна быть надлежащим образом реализована инфраструктура согласия Azure AD. Пользователь может направить запрос на вход к общедоступной конечной точке, чтобы любой клиент мог дать согласие приложению. Доступом пользователей можно управлять на основе идентификатора клиента и имени участника-пользователя, которые передаются в маркере.
  • Для использования SAML 2.0 или WS-Fed приложение должно поддерживать интеграцию единого входа SAML и (или) WS-Fed в режиме, инициируемом поставщиком услуг (SP) ли поставщиком удостоверений (IDP). Перед отправкой запроса убедитесь, что эта функция работает правильно.
  • Для выполнения единого входа с защитой паролем приложение должно поддерживать проверку подлинности с помощью формы, чтобы обеспечить хранение паролей для правильной работы функции единого входа.
  • Для тестирования вам понадобится постоянная учетная запись по крайней мере с двумя зарегистрированными пользователями.

Вы можете бесплатно получить тестовую учетную запись со всеми функциями Azure AD уровня "Премиум" на 90 дней и продлевать срок ее действия до тех пор, пока вы ведете разработку в этой учетной записи: Добро пожаловать в программу разработчиков Microsoft 365.

Шаг 1. Выбор подходящего стандарта единого входа для приложения

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

В следующей таблице сравниваются основные стандарты: Open Authentication 2.0 (OAuth 2.0) с OpenID Connect (OIDC), язык разметки заявлений системы безопасности (SAML) и Web Services Federation (WS-Fed).

Функция OAuth/OIDC SAML/WS-Fed
Единый вход с помощью веб-браузера
Единый выход с помощью веб-браузера
Единый вход на основе мобильных устройств √*
Единый выход на основе мобильных устройств √*
Политики условного доступа для мобильных приложений √*
Простой интерфейс MFA для мобильных приложений √*
Подготовка SCIM
Доступ к Microsoft Graph X

* Техническая возможность имеется, но корпорация Майкрософт не предоставляет примеры или рекомендации.

OAuth 2.0 и OpenID Connect

OAuth 2.0 — стандартный отраслевой протокол авторизации. OpenID Connect (OIDC) представляет собой стандартный отраслевой уровень проверки подлинности удостоверений, работающий поверх протокола OAuth 2.0.

Причины для выбора OAuth/OIDC

  • Штатные методы авторизации в этих протоколах обеспечивают приложению возможность доступа к богатому набору данных пользователей и организаций, а также интеграции с этими данными через API Microsoft Graph.
  • Упрощается взаимодействие с конечными пользователями ваших клиентов при внедрении единого входа в приложение. Вы можете легко задавать необходимые наборы разрешений, которые затем автоматически представляются администратору или конечному пользователю, дающему согласие.
  • Использование этих протоколов позволяет клиентам использовать политики условного доступа и многофакторной проверки подлинности (MFA) для управления доступом к приложениям.
  • Корпорация Майкрософт предоставляет библиотеки и примеры кода на различных технологических платформах, которые помогут вам в разработке.

Что следует учесть

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

SAML 2.0 или WS-Fed

SAML — это зрелый и широко распространенный стандарт единого входа для веб-приложений. Дополнительные сведения о том, как SAML используется в Azure, см. в статье "Использование протокола SAML в Azure".

Web Services Federation (WS-Fed) — это отраслевой стандарт, используемый обычно для веб-приложений на платформе .NET.

Причины для выбора SAML

  • SAML 2.0 — зрелый стандарт, и большинство технологических платформ поддерживают библиотеки с открытым исходным кодом для работы с SAML 2.0.
  • Вы можете предоставить своим клиентам интерфейс администрирования для настройки единого входа по протоколу SAML. Они тогда могут настроить единый вход на базе SAML для Microsoft Azure AD и любого другого поставщика удостоверений, поддерживающего SAML.

Что следует учесть

  • При использовании протоколов SAML 2.0 или WS-Fed для мобильных приложений некоторые политики условного доступа, включая многофакторную проверку подлинности (MFA), будут снижать качество взаимодействия пользователем.
  • Чтобы получить доступ к Microsoft Graph, необходимо реализовать авторизацию с помощью OAuth 2.0 для создания необходимых маркеров.

На основе пароля

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

Шаг 2. Реализация единого входа в приложении

Каждое приложение в коллекции должно реализовывать один из поддерживаемых способов единого входа. Дополнительные сведения о поддерживаемых способах единого входа см. в статье "Способы единого входа в Azure AD".

Подробнее об OAuth и OIDC см. в руководстве по шаблонам проверки подлинности и примерах кода с использованием Azure Active Directory.

Для использования SAML или WS-Fed приложение должно поддерживать интеграцию единого входа в режиме, инициируемом поставщиком услуг (SP) ли поставщиком удостоверений (IDP). Перед отправкой запроса убедитесь, что эта функция работает правильно.

Дополнительные сведения о проверке подлинности см. в статье "Что такое проверка подлинности?".

Важно!

Для федеративных приложений (OpenID и SAML/WS-Fed) приложение должно поддерживать модель "программное обеспечение как услуга" (SaaS). Приложения из коллекции Azure AD должны поддерживать множество конфигураций клиентов, а не какую-то одну конкретную конфигурацию.

Реализация OAuth 2.0 и OpenID Connect

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

Конкретные примеры см. в примерах кода с использованием платформы удостоверений Майкрософт.

Примеры для мобильных устройств см. по следующим ссылкам:

Реализация SAML 2.0

Если ваше приложение поддерживает SAML 2.0, его можно непосредственно интегрировать с клиентом Azure AD. Дополнительные сведения о настройке SAML для Azure AD см. в статье "Настройка единого входа на основе SAML".

Корпорация Майкрософт не предоставляет библиотеки для реализации SAML и не дает рекомендаций по выбору таких библиотек. Для этих целей существует множество библиотек с открытым исходным кодом.

Реализация WS-Fed

Дополнительные сведения о WS-Fed в ASP.NET Core см. в статье "Проверка подлинности пользователей с помощью WS-Federation в ASP.NET Core".

Реализация хранения паролей

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

Шаг 3. Реализация подготовки пользователей SCIM в приложении

Реализация поддержки подготовки пользователей средствами SCIM — необязательный, но настоятельно рекомендуемый этап создания приложения. Поддержка стандарта SCIM легко реализуется и позволяет клиентам автоматически создавать и обновлять учетные записи пользователей в вашем приложении, не полагаясь на ручные процессы, такие как отправка CSV-файлов. Кроме того, клиенты могут автоматизировать удаление пользователей и синхронизацию членства в группах, что невозможно сделать с помощью такого решения, как SAML JIT.

Подробно о SCIM

Дополнительные сведения о стандартах SCIM и их преимуществах для клиентов см. в статье "Подготовка с помощью SCIM: начало работы".

Общие сведения о реализации Azure AD SCIM

Дополнительные сведения о реализации Azure AD SCIM см. в статье "Руководство по разработке и подготовке плана для конечной точки SCIM".

Реализация SCIM

В Azure AD имеются образцы кода, которые помогут вам в создании конечной точки SCIM. Множество сторонних библиотек и ссылок можно также найти на сайте GitHub.

Шаг 4. Создание клиента Azure и тестирование в нем приложения

Чтобы протестировать приложение, вам потребуется клиент Azure AD. О том, как настроить среду разработки, см. в статью "Краткое руководство. Настройка клиента".

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

После создания клиента протестируйте единый вход и подготовку.

Приложение OIDC или OAuth необходимо зарегистрировать в качестве многоклиентского. ‎В разделе "Поддерживаемые типы учетных записей" выберите "Учетные записи в любом каталоге организации и личные учетные записи Майкрософт".

Для приложений на основе SAML и WS-Fed необходимо настроить единый вход с использованием SAML по универсальному шаблону для SAML в Azure AD.

При необходимости можно также преобразовать одноклиентское приложение в многоклиентское.

Шаг 5. Разработка и публикация документации

Документация на вашем сайте

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

Мы рекомендуем, чтобы в документации на вашем сайте присутствовали по крайней мере следующие элементы.

  • Введение в функциональность единого входа:
    • Поддерживаемые протоколы
    • версия и SKU;
    • список поддерживаемых поставщиков удостоверений с ссылками на документацию.
  • Сведения о лицензировании вашего приложения.
  • Управление доступом на основе ролей для настройки единого входа.
  • Порядок настройки SSO:
    • элементы настройки пользовательского интерфейса для SAML с ожидаемыми значениями от поставщика;
    • сведения о поставщике услуг, которые будут передаваться поставщикам удостоверений.
  • Для OIDC/OAuth:
    • список разрешений, необходимых для получения согласия, с деловыми обоснованиями.
  • Порядок тестирования для пользователей в пилотном проекте.
  • Сведения об устранении неполадок, включая коды ошибок и сообщения.
  • Механизмы поддержки для клиентов.
  • Сведения о вашей конечной точке SCIM, включая поддерживаемые ресурсы и атрибуты.

Документация на веб-сайте Майкрософт

Когда вы размещаете свое приложение в коллекции Azure Active Directory, что также приводит к его публикации в Azure Marketplace, корпорация Майкрософт создает документацию с пошаговым описанием процесса для ваших общих с Майкрософт клиентов. Пример можно найти здесь. Эта документация создается на основе сведений о приложении, которое вы отправили для публикации в коллекции, и легко обновляется при внесении изменений в приложение с использованием учетной записи GitHub.

Шаг 6. Отправка приложения

Протестировав интеграцию своего приложения с Azure AD, отправьте запрос на его публикацию через портал Microsoft Application Network.

При первой попытке входа на портал вы увидите один из двух экранов.

Если появится сообщение "Не удалось выполнить операцию", необходимо обратиться в группу интеграции единого входа Azure AD. Укажите электронный адрес, который вы хотите использовать для отправки запроса. Рекомендуется использовать рабочий электронный адрес, например name@yourbusiness.com. Команда Azure AD зарегистрирует учетную запись на портале Microsoft Application Network.

Если отображается страница "Запрос доступа", укажите деловое обоснование и выберите Запросить доступ.

После добавления учетной записи можно войти на портал Microsoft Application Network и отправить запрос, нажав на плитку Отправить запрос (ISV) на домашней странице.

Плитка "Отправить запрос (ISV)" на домашней странице

Проблемы с входом на портал

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

  • Если ваш вход был заблокирован, как показано ниже:

    Проблемы, связанные с разрешением приложения в коллекции

В чем причина?

Гостевой пользователь находится в федеративных отношениях с домашним клиентом, который также является клиентом Azure AD. Для гостевого пользователя задан высокий уровень риска. Корпорация Майкрософт не позволяет пользователям с высоким уровнем риска получать доступ к своим ресурсам. Все пользователи с высоким уровнем риска (сотрудники, гости или поставщики) должны устранить или закрыть связанный с ними риск, чтобы получить доступ к ресурсам Майкрософт. В случае гостевых пользователей этот риск исходит от домашнего клиента, а политика — из клиента, в котором располагаются запрашиваемые ресурсы (в данном случае это корпорация Майкрософт).

Безопасные решения

  • Гостевые пользователи, зарегистрированные с использованием MFA, самостоятельно устраняют связанные с ими риски. Для этого гостевой пользователь может прибегнуть к защищенному изменению или сбросу пароля (https://aka.ms/sspr) в домашнем клиенте (для этого требуется, чтобы там поддерживались MFA и SSPR). Защищенные изменение или сброс пароля должны инициироваться в Azure AD, а не в локальной системе.

  • Риски, связанных с гостевыми пользователями, устраняются их администраторами. В этом случае администратор выполняет сброс пароля (создает временный пароль). Защита идентификации для этого не требуется. Администратор гостевого пользователя может перейти на страницу https://aka.ms/RiskyUsers и нажать кнопку "Сброс пароля".

  • Риски, связанные с гостевыми пользователями, закрываются (отклоняются) их администраторами. Для этого опять-таки не требуется защита идентификации. Администратор может открыть страницу https://aka.ms/RiskyUsers и нажать кнопку "Отклонить риск для пользователя". Однако администратор должен провести комплексную экспертизу, чтобы убедиться, что оценка связанного с этим пользователем риска действительно была ложноположительной, прежде чем закрывать риск. В противном случае они ставят под угрозу свои ресурсы и ресурсы Майкрософт, действуя вопреки оценке риска без соответствующего исследования.

Примечание

Если у вас возникнут какие-либо проблемы с доступом, обратитесь в группу интеграции единого входа Azure AD.

Варианты, связанные с конкретной реализацией

Если вы хотите добавить в коллекцию приложение, использующее OpenID Connect, выберите OpenID Connect и OAuth 2.0, как описано выше.

Публикация в коллекции приложения, использующего OpenID Connect

Если вы хотите добавить в коллекцию приложение, использующее SAML 2.0 или WS-Fed, выберите SAML 2.0/WS-Fed, как описано выше.

Публикация в коллекции приложения, использующего SAML 2.0 или WS-Fed

Если вы хотите добавить в коллекцию приложение, использующее единый вход по паролю, выберите Единый вход по паролю.

Публикация в коллекции приложения, использующего единый вход по паролю

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

Запроса на подготовку пользователей

Обновление или удаление опубликованного в коллекции приложения

Обновить или удалить опубликованное в коллекции приложение вы можете на портале Microsoft Application Network.

Публикация в коллекции приложения, использующего SAML

Примечание

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

График выполнения процессов

Публикация в коллекции приложения, использующего SAML 2.0 или WS-Fed, занимает 7–10 рабочих дней.

Временная шкала публикации в коллекции приложения, использующего SAML

Публикация в коллекции приложения, использующего OpenID Connect, занимает 2–5 рабочих дней.

Временная шкала публикации в коллекции приложения, использующего OpenID Connect

Временная шкала для процесса размещения приложения подготовки SCIM в коллекции может различаться и зависит от множества факторов.

Эскалация вопросов

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

Шаг 7. Присоединение к программе Microsoft Partner Network

Программа Microsoft Partner Network обеспечивает мгновенный доступ к эксклюзивным ресурсам, программам, средствам и подключениям. Чтобы присоединиться к сети и создать план выхода на рынок, см. страницу "Обеспечьте охват клиентов из потребительского сектора".

Запрос приложений путем совместного доступа к группе приложений ISV

Клиенты могут запрашивать приложение путем предоставления сведений о приложении и контактных данных ISV здесь.

Плитка "Запросы на приложения от клиентов"

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

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

Примечание

Если у вас возникли проблемы с доступом, отправьте сообщение электронной почты Группе интеграции приложений Azure AD.

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