Экспорт (0) Печать
Развернуть все

Добавление, обновление и удаление приложения

Обновлено: Октябрь 2014 г.

В этом разделе показывается, как добавлять, обновлять или удалять приложение в Azure Active Directory (Azure AD). Вы узнаете о различных типах приложений, которые могут интегрироваться с Azure AD, как настраивать приложения для доступа к другим ресурсам, таким как веб-API, и многое другое. Дополнительные сведения о свойствах приложений см. в разделе Application Objects and Service Principal Objects.

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

При создании веб-приложения, которому требуется только вход для пользователей в Azure AD, можно просто выполнить приведенные далее инструкции. Если приложению требуется доступ к веб-API, например создается собственное приложение, которому требуется доступ к веб-API, или планируется сделать приложение мультитенантным, необходимо продолжить настройку приложения, перейдя к разделу Обновление приложения.

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

  1. Войдите на портал управления Azure.

  2. Щелкните значок Active Directory в левом меню, а затем выберите нужный каталог.

  3. В верхнем меню выберите пункт Приложения. Если в каталог не было добавлено ни одно приложение, то на этой странице будет отображаться только ссылка Добавить приложение. Щелкните эту ссылку или нажмите кнопку Добавить в панели команд.

  4. На странице Что необходимо сделать? щелкните ссылку Добавить приложение, разрабатываемое моей организацией.

  5. На странице Расскажите о своем приложении необходимо указать имя и тип приложения, которое регистрируется в Azure AD. Можно выбрать веб-приложение или веб-API (по умолчанию) или собственное клиентское приложение, которое представляет приложение, устанавливаемое на устройство, такое как телефон или компьютер.

    По завершении нажмите кнопку со стрелкой в правом нижнем углу страницы.

  6. На странице Свойства приложения укажите URL-адрес входа и URI кода приложения для веб-приложения (или только URI перенаправления для собственного клиентского приложения), а затем нажмите флажок в нижнем правом углу страницы.

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

    noteПримечание
    По умолчанию при регистрации нового приложения пользователям из вашего каталога разрешается вход в это приложение.

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

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

Новая инфраструктура согласия Azure AD облегчает разработку веб-приложений и собственных приложений, которым требуется доступ к веб-API, защищенным Azure AD. Эти веб-API включают API Graph, Office 365 и другие службы Майкрософт, а также ваши собственные веб-API. Инфраструктура строится на том, что пользователь или администратор дает согласие на регистрацию приложения в своем каталоге, что может включать доступ к данным каталога. Например, если веб-приложению требуется вызов веб-API Office 365 для чтения данных календаря, касающихся пользователя, то пользователю необходимо дать приложению согласие. После того как согласие будет дано, веб-приложение сможет вызывать веб-API Office 365 от имени пользователя и использовать данные календаря по необходимости.

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

Дополнительные сведения об инфраструктуре согласия см. в разделах OAuth 2.0 в Azure AD, Сценарии проверки подлинности в Azure AD и в статье по Office 365, посвященной проверке подлинности и авторизации с помощью общей инфраструктуры согласия.

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

  1. На странице конфигурации приложения на портале управления Azure задайте разрешения, которые требуются приложению, с помощью раскрывающихся меню в элементе управления Разрешения для других приложений.



    Разрешения для других приложений

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

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



    Вход пользователя или администратора в Microsoft Azure Active Directory

  4. После входа пользователя Azure AD будет определять, нужно ли отображать для него страницу согласия. Это зависит от того, предоставлял ли уже пользователь (или администратор его организации) согласие для этого приложения. Если согласие еще не было предоставлено, то Azure AD будет запрашивать согласие у пользователя и отображать разрешения, которые необходимы для функционирования приложения. Набор разрешений, который отображается в диалоговом окне согласия, совпадает с выбранным в элементе управления Разрешения для других приложений на портале управления Azure.



    Получение согласия от пользователя

  5. После того как пользователь даст свое согласие, в приложение возвращается код авторизации, который может быть активирован для получения токена доступа и токена обновления. Дополнительные сведения об этом потоке см. в подразделе Web Application to Web API раздела Сценарии проверки подлинности в Azure AD.

С помощью инфраструктуры согласия, описанной выше, можно настроить приложение таким образом, чтобы оно требовало разрешения, необходимые для доступа к данным, предоставляемым веб-API в вашем каталоге. По умолчанию все приложения могут выбирать разрешения из Azure Active Directory (API Graph) и API управления службами Azure с разрешением Azure AD «Enable sign on and read user’s profile» («Разрешить вход и чтение профиля пользователя»), установленным по умолчанию. Если в каталоге также имеется подписка на Office 365, то для выбора также будут доступны веб-API и разрешения для SharePoint и Exchange Online. Можно выбрать один из двух типов разрешений в раскрывающихся меню рядом с требуемым веб-API.

  • Разрешения приложения. Приложению требуется непосредственный доступ к веб-API (без контекста пользователя). Для этого типа разрешений необходимо согласие администратора, и он также недоступен для собственных клиентских приложений.

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

  1. Войдите на портал управления Azure.

  2. Щелкните значок Active Directory в левом меню, а затем выберите нужный каталог.

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

  4. На странице быстрого запуска разверните раздел доступа к веб-API в других приложениях, а затем нажмите ссылку Настроить сейчас в разделе выбора разрешений. Появится страница свойств приложения.

  5. Прокрутите вниз до раздела разрешений для других приложений. В первом столбце можно выбрать нужные из доступных приложений в каталоге, предоставляющих веб-API. После выбора приложения можно выбрать разрешения приложения и делегированные разрешения, предоставляемые веб-API.

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

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

Можно разработать веб-API и сделать его доступным для других организаций, предоставляя области разрешений разработчикам других приложений. Правильно настроенный веб-API доступен так же, как другие веб-API Майкрософт, включая API Graph и API Office 365. Веб-API делается доступным путем настройки манифеста приложения, который является JSON-файлом, представляющим конфигурацию удостоверения приложения. Чтобы предоставить области разрешений, можно перейти в приложение на портале управления Azure и нажать кнопку Манифест приложения в панели команд.

  1. Войдите на портал управления Azure.

  2. Щелкните значок Active Directory в левом меню, а затем выберите нужный каталог.

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

  4. Нажмите кнопку Управление манифестом в панели команд и выберите команду Загрузить манифест.

  5. Откройте JSON-файл манифеста приложения и замените узел “oauth2Permissions” следующим фрагментом кода JSON. Этот фрагмент кода представляет пример того, как предоставлять область разрешений, называемую олицетворением пользователя. Не забудьте изменить текст и значения на соответствующие вашему приложению.

    "oauth2Permissions": [
        {
          "adminConsentDescription": "Allow the application full access to the Todo List service on behalf of the signed-in user",
          "adminConsentDisplayName": "Have full access to the Todo List service",
          "id": "b69ee3c9-c40d-4f2a-ac80-961cd1534e40",
          "isEnabled": true,
          “origin”: “Application”
          "type": "User",
          "userConsentDescription": "Allow the application full access to the todo service on your behalf",
          "userConsentDisplayName": "Have full access to the todo service",
          "value": "user_impersonation"
        }
      ],
    

    В качестве значения id необходимо указать новый GUID, который создается с помощью инструмента создания GUID или программными средствами. Он представляет уникальный идентификатор для разрешения, предоставляемого веб-API. Когда клиент соответствующим образом настроен для запроса доступа к веб-API, при вызове этого веб-API он будет представлять токен JWT OAuth 2.0 JWT с утверждением scope (scp), установленным в value выше, которым в данном случае является значение user_impersonation.

    noteПримечание
    Позднее при необходимости можно предоставлять дополнительные области разрешений. Предположим, что веб-API может предоставлять несколько разрешений, связанных с множеством различных функций. Теперь можно управлять доступом к веб-API с помощью утверждения scope (scp) в полученном токене JWT OAuth 2.0.

  6. Сохраните обновленный JSON-файл и отправьте его, нажав кнопку Управление манифестом в панели команд, выбрав Отправить манифест, перейдя к этому обновленному файлу манифеста и затем выбрав его. После отправки веб-API становится настроенным для использования другими приложениями в каталоге.

  1. В верхнем меню щелкните элемент Приложения, выберите нужное приложение, которому нужно настроить доступ к веб-API, и нажмите кнопку Настроить.

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

    Показаны разрешения списка задач

В следующей таблице приводятся допустимые значения для части oauth2Permissions JSON-файла манифеста приложения.

 

Элемент Описание

adminConsentDescription

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

adminConsentDisplayName

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

id

Представляет уникальный внутренний идентификатор области разрешений. Это значение должно быть уникальным среди всех разрешений для приложения, а также должно быть глобальным уникальным идентификатором (GUID).

isEnabled

При создании или обновлении разрешения OAuth2 всегда имеет значение true. Если требуется удалить разрешение, сначала необходимо установить этот параметр в значение false и отправить манифест. Затем при последующей отправке манифеста можно будет удалить разрешение.

origin

Зарезервировано для использования в будущем. Всегда имеет значение «application».

тип

Может иметь одно из следующих значений:

  • “User”: согласие может быть дано конечным пользователем.

  • “Admin”: согласие должно быть дано администратором компании.

userConsentDescription

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

userConsentDisplayName

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

value

Это значение помещается в утверждение scp токена доступа OAuth 2.0, если на это конкретное разрешение пользователь дал согласие. Веб-API может использовать это значение для определения уровня доступа, который имеет приложение при олицетворении пользователя. Оно не должно содержать пробелов и должно быть уникальным среди всех разрешений в приложении.

В этом разделе описывается процесс обновления приложения для доступа к API Graph, который называется «Azure Active Directory» в списке разрешений для других приложений. Он доступен по умолчанию для всех приложений, зарегистрированных в Azure AD. В этом API Graph можно выбирать следующие разрешения.

 

Имя разрешения Описание Type

Разрешить вход и чтение профилей пользователей

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

Только делегированное разрешение. Согласие может даваться пользователями.

Доступ к каталогу организации

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

Только делегированное разрешение. В собственном клиенте согласие может даваться пользователями, в веб-приложениях — только администратором.

Чтение данных каталога

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

Делегированное разрешение и разрешение для приложения. Согласие должно даваться администратором.

Чтение и запись данных каталога

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

Делегированное разрешение и разрешение для приложения. Согласие должно даваться администратором.

Для существующих пользователей портала управления Azure установка разрешений Чтение данных каталога и Чтение и запись данных каталога с помощью нового элемента управления Разрешения для других приложений аналогична использованию предыдущего мастера Управление доступом. Сведения об областях разрешений, предоставляемых Office 365, см. в статье, посвященной проверке подлинности и авторизации с помощью общей инфраструктуры согласия.

noteПримечание
По причине текущих ограничений собственные клиентские приложения могут обращаться только к API Graph Azure AD, если они используют разрешение «Доступ к каталогу организации». Это ограничение не касается веб-приложений.

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

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

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

noteПримечание
При включении внешнего доступа необходимо убедиться, что URI кода приложения принадлежит к проверенному домену. Кроме того, URL-адрес возврата должен начинаться с https://. Дополнительные сведения см. в Application Objects and Service Principal Objects.

  1. Войдите на портал управления Azure.

  2. Щелкните значок Active Directory в левом меню, а затем выберите нужный каталог.

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

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

  5. Нажмите кнопку Да рядом с пунктом Приложение является мультитенантным, а затем нажмите кнопку Сохранить в панели команд.

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

Для предоставления доступа с помощью инфраструктуры согласия клиентское приложение должно запрашивать авторизацию с использованием OAuth 2.0. Имеются примеры кода, в которых показывается, как веб-приложение, собственное приложение или серверное/управляющее приложение запрашивают коды проверки подлинности и токены доступа для вызова веб-API.

Веб-приложение может предлагать пользователям интерфейс регистрации. Если планируется предложение интерфейса регистрации, то подразумевается, что пользователь будет нажимать кнопку регистрации (или входа), которая будет перенаправлять браузер в конечную точку авторизации OAuth 2.0 Azure AD или в конечную точку сведений о пользователях OpenID Connect. Эти конечные точки позволяют приложению получать сведения о новом пользователе, проверяя id_token.

Кроме того, веб-приложение может также предлагать интерфейс, позволяющий администраторам зарегистрировать свою организацию. Этот интерфейс также будет перенаправлять пользователя в конечную точку авторизации OAuth 2.0 Azure AD. В этом случае можно также передавать параметр prompt=admin_consent для запуска интерфейса согласия администратора, где администратор будет предоставлять согласие от имени своей организации. При успешном согласии ответ будет содержать admin_consent=true. При активации токена доступа вы также будете получать id_token, предоставляющий сведения об организации и администраторе, который зарегистрировался для вашего приложения.

В этом разделе описывается взаимодействие согласия, устаревшее с 12 марта 2014 года. Это взаимодействие по-прежнему поддерживается и описано ниже. До появления новых функциональных возможностей можно было предоставлять только следующие разрешения.

  • Вход пользователей из своей организации.

  • Вход пользователей и чтение данных каталога организации (только как приложение).

  • Вход пользователей и чтение и запись данных каталога организации (только как приложение).

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

Чтобы внешние пользователи могли зарегистрироваться в приложении, используя свои учетные записи в организации, необходимо обновить это приложение для отображения кнопки со ссылкой на страницу в Azure AD, на которой пользователи смогут предоставить доступ. Рекомендации по фирменной символике для этой кнопки регистрации см. в разделе Общие рекомендации по фирменной символике для интегрированных приложений. После того как пользователь соглашается или отклоняет доступ, страница предоставления доступа Azure AD перенаправляет браузер обратно в приложение с ответом. Дополнительные сведения о свойствах приложения см. в разделе Application Object.

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

Ссылка для приложения будет выглядеть следующим образом: http://account.activedirectory.windowsazure.com/Consent.aspx?ClientID=058eb9b2-4f49-4850-9b78-469e3176e247&RequestedPermissions=DirectoryReaders&ConsentReturnURL= https%3A%2F%2Fadatum.com%2FExpenseReport.aspx%3FContextId%3D123456. В следующей таблице описываются части этой ссылки.

 

Параметр Описание

ClientId

Обязательно. Идентификатор клиента, полученный в рамках добавления приложения.

RequestedPermissions

Необязательно. Уровень доступа, запрашиваемый приложением, который будет отображаться пользователю, предоставляющему доступ этому приложению. Если уровень доступа не указан, по умолчанию будет устанавливаться только единый вход. Другие уровни доступа — DirectoryReaders и DirectoryWriters. Дополнительные сведения об уровнях доступа см. в разделе Application Access Levels.

ConsentReturnUrl

Необязательно. URL-адрес, на который должен возвращаться ответ о предоставлении доступа. Это значение должно быть закодировано как URL-адрес и принадлежать тому же домену, что и Reply URL, настроенный в определении приложения. Если это значение не указано, ответ предоставления доступа будет направляться в настроенный Reply URL.

Указание ConsentReturnUrl отдельно от Reply URL позволит приложению применять отдельную логику обработки ответа в URL-адресе, отличном от Reply URL (в котором обычно обрабатываются токены SAML для входа). Кроме того, в закодированном как URL-адрес значении ConsentReturnURL можно указывать дополнительные параметры; они будут передаваться обратно в качестве параметров строки запроса в приложение после перенаправления. Этот механизм может использоваться для поддержки дополнительных сведений или для привязки запроса предоставления доступа приложению к ответу от Azure AD.

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

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

Войти в AAD

После проверки подлинности пользователя Azure AD перенаправляет пользователя на страницу предоставления доступа.

Предоставление доступа

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

После того как клиент предоставит доступ приложению, нажав кнопку Предоставить доступ, или отклонит запрос доступа, нажав кнопку Отмена, Azure AD отправляет ответ на ConsentReturnUrl или на настроенный Reply URL. Этот ответ содержит следующие параметры.

 

Параметр Описание

TenantId

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

Consent

Если приложению был предоставлен доступ, то будет установлено значение Granted; если запрос был отклонен, то будет установлено значение Denied.

Дополнительные параметры будут возвращаться в приложение, только если они были заданы как часть зашифрованного как URL-адрес значения ConsentReturnUrl. Пример ответа на запрос предоставления доступа, указывающего, что приложение авторизовано, и включающего ContextID, предоставленный в запросе предоставления доступа: https://adatum.com/ExpenseReport.aspx?ContextID=123456&Consent=Granted&TenantId=f03dcba3-d693-47ad-9983-011650e64134

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

Ниже приведен пример ответа на запрос предоставления доступа, который был отклонен. https://adatum.com/ExpenseReport.aspx?ContextID=123456&Consent=Denied

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

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

  2. Выберите пункт Настройка в верхнем меню, чтобы просмотреть список свойств приложения и увидеть список ключей.

  3. В разделе Ключи щелкните раскрывающийся список выбора длительности, выберите срок 1 или 2 года и нажмите кнопку Сохранить в панели команд. Будет создан новый парольный ключ для приложения. Скопируйте этот новый парольный ключ. На этот момент приложение может использовать и существующий, и новый ключ для получения токена доступа от Azure AD.

  4. Вернитесь в приложение и обновите конфигурацию, чтобы начать использовать новый парольный ключ. Пример, показывающий, где должно происходить это обновление, см. в разделе Использование API Graph для запроса в Azure AD.

  5. Теперь следует развернуть это изменение в рабочей среде — проверьте его на одном узле обслуживания, прежде чем развертывать в остальных.

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

После включения доступа внешних пользователей к приложению по-прежнему можно вносить изменения в свойства приложения на портале управления Azure. Однако клиенты, предоставившие доступ приложению before внесения в него изменений, не будут видеть эти изменения при просмотре сведений о приложении на портале управления Azure. Необходимо соблюдать осторожность при внесении некоторых изменений в приложение, после того как оно стало доступным клиентам. Например, если обновить App ID URI, то существующие клиенты, предоставившие доступ до этого изменения, не смогут входить в это приложение с учетной записью, предоставленной их организацией или учебным заведением.

Если изменить RequestedPermissions, чтобы запрашивался более высокий уровень доступа, то существующие пользователи функциональных возможностей приложения, которое теперь использует новые вызовы API с увеличенным уровнем доступа, могут получить от API Graph отказ в доступе. Приложение должно обрабатывать такие ситуации и запрашивать у клиента предоставление приложению увеличенного уровня доступа.

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

  1. Войдите на портал управления Azure.

  2. Щелкните значок Active Directory в левом меню, а затем выберите нужный каталог.

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

  4. Нажмите кнопку Удалить в панели команд.

  5. Нажмите кнопку Да в сообщении подтверждения.

  1. Войдите на портал управления Azure.

  2. Щелкните значок Active Directory в левом меню, а затем выберите нужный каталог.

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

  4. В разделе Приложение является мультитенантным нажмите Нет. Это преобразует приложение в приложение одного клиента, но оно по-прежнему останется в тех организациях, которые согласились с ним.

  5. Нажмите кнопку Удалить в панели команд.

  6. Нажмите кнопку Да в сообщении подтверждения.

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

Показ:
© 2014 Microsoft