API JavaScript для проверки подлинности

Статья
11/11/2024

Интерфейс Fabric предлагает API JavaScript для рабочих нагрузок Fabric для получения маркера для приложения в идентификаторе Microsoft Entra. В этой статье описывается этот API.

API

acquireAccessToken(params: AcquireAccessTokenParams): Promise<AccessToken>;  
export interface AcquireAccessTokenParams {
    additionalScopesToConsent?: string[];  
    claimsForConditionalAccessPolicy?: string;
    promptFullConsent?: boolean;
}

API возвращает объект AccessToken, содержащий сам маркер и дату окончания срока действия маркера.

Чтобы вызвать API в примере внешнего интерфейса, создайте пример элемента, а затем прокрутите вниз и выберите "Перейти к проверке подлинности". В этом случае можно выбрать маркер доступа, чтобы получить маркер обратно.

Снимок экрана: раздел проверки подлинности.

Соглашается

Чтобы понять, почему требуется согласие пользователей и администраторов, перейдите по идентификатору Microsoft Entra ID.

Примечание.

Для работы и получения маркеров между клиентами требуются разрешения CRUD/Jobs.

Как работают разрешения в рабочих нагрузках Fabric?

Чтобы предоставить согласие для конкретного приложения, Fe Fabric создает экземпляр MSAL , настроенный с идентификатором приложения рабочей нагрузки, и запрашивает маркер для указанных областей (дополнительные области (дополнительные области — см. раздел AcquireAccessTokenParams).

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

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

В нашем случае это не в том же домене, так как Структура запрашивает маркер и URI перенаправления рабочей нагрузки не находится в домене Fabric. Поэтому при открытии диалогового окна согласия его необходимо закрыть вручную после перенаправления. Мы не используем код, возвращенный в URI перенаправления, поэтому мы просто автоклозируем его (когда идентификатор Microsoft Entra ID перенаправляет всплывающее окно в универсальный код ресурса (URI перенаправления) он просто закрывается.

Код и конфигурация URI перенаправления можно увидеть в файле index.ts .

Ниже приведен пример всплывающего окна согласия для приложения "мое приложение рабочей нагрузки" и его зависимостей (хранилища и Power BI), настроенных при настройке проверки подлинности:

Снимок экрана: диалоговое окно

Другой способ предоставления согласия в домашнем клиенте (необязательно)

Чтобы получить согласие в домашнем клиенте приложения, вы можете попросить администратора клиента предоставить согласие для всего клиента, используя URL-адрес в следующем формате (вставьте собственный идентификатор клиента и идентификатор клиента):

https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={clientId}

AcquireAccessTokenParams

При вызове API acquireAccessToken JS можно указать три параметра:

additionalScopesToConsent: другие области, чтобы запросить согласие, например о повторном развертывании сценариев.
claimsForConditionalAccessPolicy: утверждения, возвращаемые из идентификатора Microsoft Entra ID при сбое потоков OBO, например для OBO требуется многофакторная проверка подлинности.
promptFullConsent: запрашивает полное окно согласия статических зависимостей приложения рабочих нагрузок.

additionalScopesToConsent

Если интерфейс рабочей нагрузки запрашивает маркер, используемый для вызовов серверной части рабочей нагрузки, этот параметр должен иметь значение NULL. Серверная часть рабочей нагрузки может не выполнить OBO на маркере, полученном из-за ошибки согласия, в этом случае серверной части рабочей нагрузки потребуется распространить ошибку на интерфейс рабочей нагрузки и указать этот параметр.

claimsForConditionalAccessPolicy

Этот параметр используется при сбоях OBO в рабочей нагрузке BE из-за определенной политики условного доступа, настроенной в клиенте.

Сбои OBO из-за политик условного доступа возвращают строку с именем "утверждения". Эта строка должна быть отправлена в рабочую нагрузку FE, в которой FE должен запрашивать маркер и передавать утверждение в качестве claimsForConditionalAccessPolicy. Дополнительные сведения см. в разделе "Обработка многофакторной проверки подлинности" (MFA), условного доступа и добавочного согласия.

Ознакомьтесь с примером использования AuthenticationService AddBearerClaimToResponse в примере BE, чтобы просмотреть примеры ответов при сбое операций OBO из-за отсутствия согласия или политик условного доступа.

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

promptFullConsent

При передаче как true полное согласие статических зависимостей появится для пользователя независимо от того, предоставлено ли оно согласие ранее или нет. Пример использования этого параметра — добавить кнопку в ПОЛЬЗОВАТЕЛЬСКИЙ интерфейс, где пользователь может использовать его для предоставления полного согласия рабочей нагрузке.

Поделиться через