Существует несколько способов управления проверкой подлинности в Azure, особенно для крупных организаций, использующих каталоги Active Directory / Azure AD. Но для вашего случая вы должны использовать исключительно Azure AD B2C (вам не нужен бизнес-справочник).

Поскольку есть награда, требующая чего-то немного другого, я разделю ее на две части.

• Часть 1. Я хочу использовать метод аутентификации через Azure с публичной регистрацией (Azure AD B2C).
• Часть 2. Я хочу использовать метод аутентификации через Azure с учетными данными Active Directory (Azure AD).

Полезная информация

Маленькое напоминание:

• Active Directory = локальный бизнес-справочник, разработанный Microsoft в течение многих лет (1999 г.) крупными компаниями и находящийся исключительно в разрешении.
• Azure Active Directory = современный бизнес-каталог, адаптированный к требованиям облака. Иногда он синхронизируется с локальным активным каталогом, чтобы обеспечить гибкость между локальным миром и облаком. (Office 365 полностью зависит от Azure AD.)
• Azure Active Directory B2C = современный каталог пользователей, подходящий для регистрации клиентов. Он обеспечивает систему управления идентификацией с автоматической регистрацией. (Я не буду объяснять преимущества этой услуги по сравнению с классическим управлением идентификацией, это не предмет, но вы легко найдете информацию здесь: https://azure.microsoft.com/en-us/services/active-directory-b2c/) -> Важно: это расширение Azure Active Directory.

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

Часть 1. Я хочу использовать метод аутентификации через Azure с публичной регистрацией (Azure AD B2C).

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

1.1 Как это работает?

При создании службы Azure AD B2C она сначала создала каталог Azure AD с выбранным именем и суффиксом DNS.onmicrosoft.com. Затем он автоматически связал этот новый каталог со службой Azure AD B2C. Пользователь, который регистрируется по электронной почте, будет добавлен в каталог Azure AD. Это ваша база данных.

С этого момента мы считаем, что новые пользователи могут зарегистрироваться непосредственно в каталоге Azure AD через Azure AD B2C.

Чтобы быстро схематизировать операцию:

1. Клиент нажимает "Подключиться" с ваших серверов.
2. Ваш сценарий на сервере перенаправляет на URL-адрес службы Azure AD B2C (обычно с DNS-суффиксом, например, b2clogin.com или microsoftonline.com).
3. Оттуда ваш клиент увидит страницу, которую вы можете свободно настроить, предлагая подключиться с помощью логина / пароля (с / без MFA) или зарегистрироваться.
4. Клиент нажимает для входа / регистрации, и Azure AD B2C возвращает маркер аутентификации на ваш сервер.
5. Ваш сервер (ваш код) использует этот токен (потому что он связывается с Azure AD B2C через REST API (MSAL)) и разрешает или запрещает доступ к вашему приложению.

1.2 Как мне настроить его из Azure?

Есть два важных шага (я оставляю вам открыть для себя другие варианты):

Зарегистрировать приложение:

• Просто создайте информацию о конфигурации для подключения к API-интерфейсу REST Azure AD B2C из своей программы.
• Что настраивать:
  • Вы должны активировать веб-API
  • Вы должны указать URL-ответ:
  • Это URL вашего веб-сервиса, который будет извлекать информацию, передаваемую Azure AD B2C. Здесь ваш код будет проверять подлинность пользователя и может продолжать навигацию.
  • Любой URL действителен, если вы знаете, как восстановить передаваемые переменные POST.
  • Изображение: Регистрация приложения
  • Обратите внимание на приложение ID, которое будет использоваться для настройки вашего скрипта.

Создайте пользовательский поток:

• Здесь вы настраиваете свои стратегии на то, что клиент увидит, когда они будут на странице входа.
• Что настраивать:
  • Вы должны выбрать опцию "Зарегистрироваться и войти" (другие вы сделаете позже, но вот интересная ссылка: https://docs.microsoft.com/en-us/azure/active-directory-b2c/user-flow-versions).
  • Выберите провайдера идентификации "Электронная почта"
  • (Вы можете наблюдать МИД здесь, мы вернемся к нему позже)
  • Выберите атрибуты, которые вы хотите использовать:
  • Атрибут Collect = что Azure AD B2C будет собирать в своей базе данных.
  • Запрос на возврат = Что Azure AD B2C вернет в дополнение к вашему серверу в ответе URL.
  • Изображение: пользовательский поток
• Осознав, вы сможете подготовить ваше веб-приложение для его использования.

1.3 Как мне настроить его из моего веб-приложения?

• Отличная ссылка, чтобы быстро понять, что делать: https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-quickstarts-spa
• Я буду использовать образец этой ссылки, чтобы объяснить, что делать.
  • В JavaScript index.html мы видим обращения к API Azure AD B2C через модуль MSAL.js.
  • MSAL = библиотека аутентификации Microsoft: https://github.com/AzureAD/microsoft-authentication-library-for-js
  • MSAL выполняет "всю работу", чтобы разрешить перенаправление и возврат для проверки подлинности или без проверки подлинности.
• В строке 52 мы видим переменную msalConfig:

var msalConfig = {
    auth: {
        clientId: "e760cab2-b9a1-4c0d-86fb-ff7084abd902", // This is your client ID
        authority: "https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_susi", // This is your holding info
        validateAuthority: false
    }
    hidden: {
        cacheLocation: "localStorage",
        storeAuthStateInCookie: true
    }
};

• Вы должны зарегистрировать его ClientId (который соответствует ранее зарегистрированному в Azure AD B2C)

• И полномочия с окончанием имени вашего пользовательского потока, например для меня, будут такими: https://makoad.b2clogin.com/makoAD.onmicrosoft.com/B2C_1_Default2

  • В строке 122 у нас есть функция callApiWithAccessToken, которая показывает, как мы используем токен, полученный MSAL

            headers: {
              'Authorization': 'Bearer' + accessToken,
            }

• Это классика, accessToken - это паспорт пользователя для продолжения использования ваших страниц. Оттуда вы можете вызывать все запросы GET / POST / PUT, необходимые для правильного получения идентификатора пользователя и использования его на ваших страницах.
• Я могу дать больше информации, если это необходимо, но я думаю, что образец страницы достаточно, чтобы понять.

1.4 Как настроить MFA и условный доступ?

• К сожалению, пока невозможно использовать условный доступ в случае MFA в Azure AD B2C.
• Условный доступ и MFA работают только с Azure AD. (Azure AD не разрешит публичную регистрацию пользователей -> Есть еще способы сделать это, но это займет время)

Часть 2. Я хочу использовать метод аутентификации через Azure с учетными данными Active Directory (Azure AD).

• Работа в процессе.:) (это немного долго)

Надеюсь, это поможет кому-то. (Трудно все объяснить, заранее извините, чтобы избежать некоторых сведений)

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

Я буду ссылаться на Azure Active Directory как AAD на протяжении всего этого.

Что такое AAD

Давайте быстро поговорим о том, что такое AAD, а что нет. AAD не является Active Directory. Единственное, что у них общего, - это имя. AAD - это не LDAP, он не поддерживает RADIUS и не может выступать в качестве конечной точки Active Directory для чего-либо, для чего требуется активная конечная точка каталога.

AAD - это сервис аутентификации на основе REST API. Он поддерживает OAuth 2, и я считаю, что также SAML. Все, что вы настраиваете, должно использовать эти конечные точки для аутентификации.

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

Возможные варианты

Шлюз приложений Azure

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

Документация шлюза приложений Azure

Сторонний прокси-сервер аутентификации

Если вы используете Apache, nginx или что-то подобное перед развертыванием, вы можете обеспечить доступ к веб-сайту с помощью стороннего прокси-сервера аутентификации, такого как Skipper. Вам потребуется развернуть службу шкипера и настроить ее для подключения к конечной точке AAD OAuth для вашего клиента.

Неспособные варианты

Прокси приложения Azure

Это не предназначено для использования с приложениями, размещенными на Azure, как вы упоминаете в своем вопросе.

Сторонний шлюз VPN

Я не знаю ни одного VPN-сервера, который бы поддерживал OAuth или SAML в качестве внутреннего механизма. Я не думаю, что OpenVPN поддерживает это, и это наиболее часто используемый VPN-сервер. Возможно, опция может существовать, хотя.

Azure VPN-шлюз

Если вы хотите пройти проверку подлинности с помощью ADD, это на самом деле не вариант, поскольку шлюз Azure VPN позволяет выполнять проверку подлинности только по протоколу TLS или RADIUS, ни один из которых не совместим с AAD. В результате это нереальный вариант.