Руководство. Перенос из службы контроля доступа Azure
Предупреждение
В этом руководстве используется устаревшая конечная точка Azure Active Directory версии 1.0. Для новых проектов используйте платформу удостоверений Майкрософт.
Служба контроля доступа Microsoft Azure (ACS), относящаяся к Azure Active Directory (Azure AD), прекратит функционирование 7 ноября 2018 г. До того времени приложения и службы, использующие службу контроля доступа, должны быть полностью перенесены в другой механизм проверки подлинности. В этой статье описываются рекомендации, которые помогут текущим клиентам спланировать отказ от использования службы контроля доступа. Если в настоящее время вы не используете службу контроля доступа, не предпринимайте никаких действий.
Общие сведения
Служба контроля доступа — это облачная служба проверки подлинности, которая предлагает простой способ проверки подлинности и авторизации пользователей для получения доступа к веб-приложениям и службам. Она позволяет реализовать множество функциональных возможностей проверки подлинности и авторизации в своем коде. Служба контроля доступа в основном используется разработчиками и архитекторами клиентов Microsoft .NET, веб-приложений ASP.NET и веб-служб Windows Communication Foundation (WCF).
Варианты использования службы контроля доступа (ACS) можно разделить на три основные категории:
- Проверка подлинности в определенных облачных службах Майкрософт, включая служебную шину Azure и Dynamics CRM. Клиентские приложения получают маркеры из службы контроля доступа, а затем проходят с их помощью проверку подлинности в этих службах и выполняют различные действия.
- Добавление проверки подлинности в веб-приложения, как пользовательские, так и предварительно упакованные (например, SharePoint). Пассивная проверка подлинности службы контроля доступа позволяет входить в веб-приложения с помощью учетной записи Майкрософт (ранее Live ID) и с помощью учетных записей Google, Facebook, Yahoo, Azure AD и служб федерации Active Directory (AD FS).
- Защита пользовательских веб-служб с помощью маркеров, выданных службой контроля доступа. Использование активной проверки подлинности гарантирует, что к веб-службам могут получить доступ только доверенные клиенты, прошедшие проверку подлинности в службе контроля доступом.
В разделах ниже рассматривается каждый из этих вариантов использования и рекомендуемые стратегии переноса.
Предупреждение
В большинстве случаев, чтобы перенести имеющиеся приложения и службы на более новые технологии, нужно значительно изменить код. Мы советуем немедленно приступить к планированию и непосредственно к самому переносу, чтобы избежать возможных сбоев и простоев.
Служба контроля доступа содержит следующие компоненты:
- Служба маркеров безопасности (STS), которая получает запросы на проверку подлинности и взамен выдает маркеры безопасности.
- Классический портал Azure, где можно создавать, удалять, включать и отключать пространства имен службы контроля доступа.
- Отдельный портал управления контролем доступа, где можно настроить пространства имен службы контроля доступа.
- Служба управления, позволяющая автоматизировать функции порталов.
- Модуль правил преобразования маркеров, с помощью которого можно определить сложную логику обработки выходного формата маркеров, выданных службой контроля доступа.
Чтобы использовать эти компоненты, необходимо создать одно или несколько пространств имен службы контроля доступа. Пространство имен — это выделенный экземпляр службы контроля доступа, с которым ваши службы и приложения обмениваются данными. Пространство имен изолировано от всех других клиентов службы контроля доступа. Они используют собственные пространства имен. Пространство имен в службе контроля доступом имеет выделенный URL-адрес, который выглядит следующим образом:
https://<mynamespace>.accesscontrol.windows.net
По этому URL-адресу выполняется весь обмен данными с STS и операции управления. Для разных целей используются разные пути. Чтобы определить, используют ли службы или приложения службу контроля доступа, отслеживайте трафик к https://<пространство имен>.accesscontrol.windows.net. Любой трафик к этому URL-адресу обрабатывается с помощью службы контроля доступа, и его нужно прекратить.
Исключением является весь трафик к https://accounts.accesscontrol.windows.net. Трафик к этому URL-адресу уже обрабатывается другой службой. Прекращение поддержки службы контроля доступа не влияет на него.
Дополнительные сведения о службе ACS см. в статье Служба Access Control Service 2.0.
Определение затронутых приложений
Выполните описанные ниже действия, чтобы узнать, на какие приложения повлияет прекращение поддержки ACS.
Загрузка и установка ACS PowerShell
Перейдите в коллекцию PowerShell и загрузите Acs.Namespaces.
Установите модуль, выполнив следующую команду:
Install-Module -Name Acs.NamespacesПолучите список всех возможных команд, выполнив следующую команду:
Get-Command -Module Acs.NamespacesЧтобы получить справку по конкретной команде, выполните следующую команду:
Get-Help [Command-Name] -Fullгде
[Command-Name]— это имя команды ACS.
Получение списка пространств имен ACS
Подключитесь к ACS с помощью командлета Connect-AcsAccount.
Возможно, перед выполнением команд нужно будет выполнить
Set-ExecutionPolicy -ExecutionPolicy Bypass, а также потребуются права администратора подписок.Получите список доступных подписок Azure с помощью командлета Get-AcsSubscription.
Получите список пространств имен ACS с помощью командлета Get-AcsNamespace.
Проверка влияния на приложения
Используйте пространство имен из предыдущего этапа и перейдите к
https://<namespace>.accesscontrol.windows.net.Например, если одним из пространств имен является contoso-test, перейдите к
https://contoso-test.accesscontrol.windows.net.В разделе Отношения доверия выберите Приложения проверяющей стороны, чтобы просмотреть список приложений, которые затронет прекращение поддержки ACS.
Повторите шаги 1 и 2 для других пространств имен ACS.
График прекращения использования
По состоянию на ноябрь 2017 г. все компоненты службы контроля доступа полностью поддерживаются и находятся в рабочем режиме. Единственным ограничением является невозможность создания новых пространств имен контроля доступа через классический портал Azure.
Вот график устаревания компонентов службы контроля доступа:
- Ноябрь 2017 года. Прекращается использование интерфейса администрирования Azure AD на классическом портале Azure. На этом этапе управлять пространством имен службы контроля доступа можно по следующему новому выделенному URL-адресу:
https://manage.windowsazure.com?restoreClassic=true. По этому URL-адресу можно просматривать существующие пространства имен, включать, отключать и удалять их. - 2 апреля 2018 года. Использование классического портала Azure полностью прекращено, то есть управление пространствами имен службы контроля доступа через любой URL-адрес больше недоступно. Вы больше не сможете отключить, включить, удалить или перечислить пространства имен контроля доступа. Однако портал управления службы контроля доступа будет полностью функционален и размещен по адресу
https://<namespace>.accesscontrol.windows.net. Все другие компоненты службы контроля доступом будут по-прежнему работать в обычном режиме. - 7 ноября 2018 года. Все компоненты службы контроля доступа будут окончательно отключены. К ним относится портал управления службы контроля доступа, служба управления, STS и модуль правил преобразования маркеров. На этом этапе все запросы, отправленные к контролю доступа (по адресу
<namespace>.accesscontrol.windows.net), завершаются ошибкой. До этого времени вы должны перенести все имеющиеся приложения и службы на другие технологии.
Примечание
Политика отключает пространства имен, которые не запрашивали токен в течении определенного периода времени. По состоянию на начало сентября 2018 года этот период времени составляет 14 дней бездействия, но в ближайшие недели он сократится до 7 дней бездействия. Если у вас есть пространства имен контроль доступа, которые в настоящее время отключены, вы можете загрузить и установить ACS PowerShell для повторного их включения.
Стратегии миграции
В следующих разделах приведены общие рекомендации по переходу с службы контроля доступа на другие технологии Майкрософт.
Клиенты облачных служб Майкрософт
Каждая из облачных служб Майкрософт, которые принимают маркеры, выданные службой контроля доступа, поддерживает по крайней мере один альтернативный способ проверки подлинности. Правильный же механизм зависит от каждой службы, поэтому мы советуем воспользоваться рекомендациями из соответствующей документации. Для удобства ниже приведен каждый набор документации.
| Служба | Руководство |
|---|---|
| Служебная шина Azure | Переход от службы контроля доступа Azure Active Directory к авторизации подписанного URL-адреса |
| Ретрансляция служебной шины Azure | Переход от службы контроля доступа Azure Active Directory к авторизации подписанного URL-адреса |
| Управляемый кэш Azure | Миграция в службу "Кэш Azure для Redis" |
| Azure DataMarket | Переход на API служб ИИ Azure |
| Службы BizTalk | Переход на компонент Logic Apps службы приложений Azure |
| Службы мультимедиа Azure | Azure Media Services announces support for Azure AD and deprecation of Access Control authentication (Команда разработчиков служб мультимедиа Azure анонсирует поддержку проверки подлинности AAD и объявление проверки подлинности ACS устаревшей) |
| Azure Backup | Вопросы об агенте службы Azure Backup |
Клиенты SharePoint
Клиенты SharePoint 2013, SharePoint 2016 и SharePoint Online давно используют службу контроля доступа для аутентификации в облачных, локальных и гибридных средах. Прекращение использования службы контроля доступа повлияет на некоторые функции и варианты использования SharePoint. В таблице ниже приведены краткие инструкции по миграции для некоторых из наиболее популярных компонентов SharePoint, использующих службу контроля доступа.
| Компонент | Руководство |
|---|---|
| Аутентификация пользователей из Azure AD | Ранее в Azure AD не поддерживались маркеры SAML 1.1, необходимые SharePoint для аутентификации, и служба контроля доступа использовалась в качестве посредника, обеспечивающего совместимость SharePoint с форматами маркеров Azure AD. Теперь вы можете подключить SharePoint непосредственно к Azure AD, используя локальное приложение SharePoint из коллекции приложений Azure AD. |
| Аутентификация приложений и аутентификация между серверами в локальной среде SharePoint | Не зависит от прекращения использования службы контроля доступа. Какие-либо изменения не требуются. |
| Авторизация с низким уровнем доверия для надстроек SharePoint (при размещении у поставщика и размещении в SharePoint) | Не зависит от прекращения использования службы контроля доступа. Какие-либо изменения не требуются. |
| Гибридный поиск в облаке SharePoint | Не зависит от прекращения использования службы контроля доступа. Какие-либо изменения не требуются. |
Веб-приложения, использующие пассивную проверку подлинности
Для веб-приложений, использующих службу контроля доступа для проверки подлинности пользователей, эта служба предоставляет веб-разработчикам и архитекторам таких приложений следующие функции и возможности:
- Тесная интеграция с Windows Identity Foundation (WIF).
- Федерация с учетными записями Google, Facebook, Yahoo, Azure Active Directory, ADFS и учетными записями Майкрософт.
- Поддержка следующих протоколов проверки подлинности: OAuth 2.0 (черновой вариант 13), WS-Trust и Web Services Federation (WS-Federation).
- Поддержка следующих форматов маркеров: JWT, SAML 1.1, SAML 2.0 и SWT.
- Возможность обнаружения домашней области, интегрированная в WIF, благодаря которой пользователи могут выбирать тип учетной записи для входа. Эта возможность реализована в веб-приложении и полностью настраиваемая.
- Преобразование маркеров, позволяющее настраивать утверждения, полученные веб-приложением из службы контроля доступа, в том числе:
- отправка утверждений от поставщиков удостоверений;
- добавление дополнительных настраиваемых утверждений;
- выдача утверждений при определенных условиях на основе простой логики If-Then.
К сожалению, ни одна служба не предлагает все соответствующие возможности. Вы должны оценить, какие возможности контроль доступа вам нужны, а затем выбрать между использованием идентификатора Microsoft Entra, Azure Active Directory B2C (Azure AD B2C) или другой облачной службы проверки подлинности.
Переход на идентификатор Microsoft Entra
Следует рассмотреть возможность интеграции приложений и служб непосредственно с идентификатором Microsoft Entra. Microsoft Entra id — это облачный поставщик удостоверений для рабочих или учебных учетных записей Майкрософт. Microsoft Entra id — это поставщик удостоверений для Microsoft 365, Azure и многих других. Он предоставляет такие же возможности федеративной проверки подлинности, что и служба контроля доступа, но не поддерживает множество других функций этой службы.
Основной пример — федерация с поставщиками удостоверений социальных сетей, таких как Facebook, Google и Yahoo. Если пользователи входят с учетными данными этих типов, Microsoft Entra идентификатор не является решением для вас.
Microsoft Entra идентификатор также не обязательно поддерживает те же протоколы проверки подлинности, что и контроль доступа. Например, хотя ИД контроль доступа и Microsoft Entra поддерживают OAuth, между каждой реализацией существуют незначительные различия. существенно отличается.
Однако идентификатор Microsoft Entra предоставляет ряд потенциальных преимуществ для контроль доступа клиентов. Эта служба изначально поддерживает размещенные в облаке рабочие и учебные учетные записи Майкрософт, которые часто используют клиенты службы контроля доступа.
Клиент Microsoft Entra также может быть объединено в федерацию с одним или несколькими экземплярами локальная служба Active Directory через AD FS. Таким образом в приложении могут проходить проверку подлинности как облачные пользователи, так и пользователи, размещенные в локальной среде. Кроме того, Azure AD поддерживает протокол WS-Federation, за счет чего эту службу сравнительно легко интегрировать с веб-приложениями с помощью WIF.
В следующей таблице сравниваются функции контроль доступа, относящиеся к веб-приложениям, с функциями, доступными в идентификаторе Microsoft Entra.
На высоком уровне идентификатор Microsoft Entra, вероятно, является лучшим выбором для миграции, если пользователи могут выполнять вход только с помощью рабочих или учебных учетных записей Майкрософт.
| Функция | Поддержка службы контроля доступа | Поддержка идентификаторов Microsoft Entra |
|---|---|---|
| Типы учетных записей | ||
| Рабочие и учебные учетные записи Майкрософт | Поддерживается | Поддерживается |
| Учетные записи Windows Server Active Directory и AD FS | — Поддерживается через федерацию с клиентом Microsoft Entra. — Поддерживаются через прямую федерацию с AD FS |
Поддерживается только через федерацию с клиентом Microsoft Entra |
| Учетные записи других корпоративных систем управления удостоверениями | — Возможно через федерацию с клиентом Microsoft Entra. — Поддерживаются через прямую федерацию |
Возможно через федерацию с клиентом Microsoft Entra |
| Личные учетные записи Майкрософт | Поддерживается | Поддерживается по протоколу OAuth Microsoft Entra версии 2.0, но не по другим протоколам |
| Учетные записи Facebook, Google, Yahoo | Поддерживается | Не поддерживаются ни при каких обстоятельствах |
| Совместимость с протоколами и пакетом SDK | ||
| WIF | Поддерживается | Поддерживается, но с определенными условиями |
| WS-Federation | Поддерживается | Поддерживается |
| OAuth 2.0 | Поддерживается черновая версия 13 | Поддерживается RFC 6749 (последняя спецификация) |
| WS-Trust | Поддерживается | Не поддерживается |
| Форматы маркеров | ||
| JWT | Поддерживается в бета-версии | Поддерживается |
| SAML 1.1 | Поддерживается | Предварительный просмотр |
| SAML 2.0 | Поддерживается | Поддерживается |
| SWT | Поддерживается | Не поддерживается |
| Настройки | ||
| Настраиваемый пользовательский интерфейс обнаружения домашней области и выбора учетной записи | Загружаемый код, который можно включить в приложения | Не поддерживается |
| Передача пользовательских сертификатов для подписи маркера | Поддерживается | Поддерживается |
| Настройка утверждений в маркерах | — Отправка входящих утверждений от поставщиков удостоверений — Получение маркера доступа от поставщика удостоверений как утверждения — Выдача исходящих утверждений на основе значений входящих утверждений — Выдача исходящих утверждений с постоянными значениями |
— Не может отправлять утверждения от федеративных поставщиков удостоверений — Не может получить маркер доступа от поставщика удостоверений как утверждение — Не может выдавать исходящие утверждения на основе значений входящих утверждений — Не может выдавать исходящие утверждения с постоянными значениями — может выдавать выходные утверждения на основе свойств пользователей, синхронизированных с идентификатором Microsoft Entra. |
| Служба автоматизации | ||
| Автоматизация задач настройки и управления | Поддерживается через службу управления контролем доступа | Поддерживается с помощью API-интерфейса Microsoft Graph |
Если вы решите, что Microsoft Entra ID является оптимальным способом миграции для ваших приложений и служб, следует учитывать два способа интеграции приложения с Microsoft Entra ID.
Чтобы использовать WS-Federation или WIF для интеграции с Microsoft Entra ID, рекомендуется следовать подходу, описанному в разделе Настройка федеративного единого входа для приложения, не из коллекции. В этой статье описывается настройка идентификатора Microsoft Entra для единого входа на основе SAML, но также описывается настройка WS-Federation. Для этого подхода требуется лицензия Microsoft Entra идентификатор P1 или P2. Такой подход имеет два преимущества:
- Вы получаете полную гибкость настройки маркера Microsoft Entra. Утверждения, выданные идентификатором Microsoft Entra, можно настроить в соответствии с утверждениями, выданными контроль доступа. Это особенно касается утверждения идентификатора имени и пользователя. Чтобы после изменения технологий по-прежнему получать согласованные идентификаторы пользователей, убедитесь, что идентификаторы пользователей, выданные Microsoft Entra идентификаторами, совпадают с идентификаторами, выданными контроль доступа.
- Вы можете настроить сертификат для подписи маркера, специфичный для вашего приложения, временем существования которого управляете вы.
Примечание
Для этого подхода требуется лицензия Microsoft Entra ИД P1 или P2. Если вы клиент ACS и вам требуется лицензия Premium, чтобы настроить единый вход в приложение, обратитесь к нам, и мы предоставим лицензии разработчика.
Кроме того, вы можете использовать этот пример кода, в котором реализован немного другой подход к настройке WS-Federation. В этом примере кода используется не WIF, а ПО промежуточного слоя ASP.NET 4.5 OWIN. Однако инструкции по регистрации приложений действительны для приложений, использующих WIF, и не требуют лицензии Microsoft Entra P1 или P2.
При выборе этого подхода необходимо понимать смену ключа подписывания в Microsoft Entra id. В этом подходе для выдачи маркеров используется глобальный ключ подписывания Microsoft Entra. По умолчанию WIF не обновляет ключи подписывания автоматически. Когда Microsoft Entra ID меняет глобальные ключи подписывания, необходимо подготовить реализацию WIF к принятию изменений. Дополнительные сведения см. в статье Важные сведения о смене ключа подписывания в Microsoft Entra ID.
Если вы можете выполнить интеграцию с Microsoft Entra ID с помощью протоколов OpenID Connect или OAuth, рекомендуется сделать это. У нас есть обширная документация и рекомендации по интеграции Microsoft Entra ID в веб-приложение, доступные в нашем руководстве разработчика Microsoft Entra.
Переход на Azure Active Directory B2C
Еще один вариант переноса, который следует рассмотреть, — это Azure AD B2C. Azure AD B2C — это облачная служба проверки подлинности, аналогичная службе контроля доступа. Она позволяет разработчикам развернуть в облачной службе логику управления удостоверениями и проверки подлинности сторонних поставщиков. Эта платная служба (с уровнями "Бесплатный" и "Премиум") предназначена для клиентов, создающих приложения, которые могут иметь миллионы активных пользователей.
Одна из наиболее привлекательных возможностей Azure AD B2C (как и службы контроля доступа) заключается в поддержке большого количества разных типов учетных записей. С помощью Azure AD B2C пользователи могут выполнять вход, используя свою учетную запись Майкрософт, учетные записи Facebook, Google, LinkedIn, GitHub или Yahoo и многие другие. Кроме того, Azure AD B2C поддерживает локальные учетные записи — имена пользователей и пароли, создаваемые пользователями специально для определенного приложения. Azure AD B2C также предоставляет широкие возможности расширяемости, с помощью которых можно настроить потоки входа.
Однако эта служба не поддерживает все протоколы проверки подлинности и форматы маркеров, необходимые клиентам службы контроля доступа. С помощью Azure AD B2C также нельзя получить маркеры и запросить дополнительные сведения о пользователе от поставщика удостоверений, корпорации Майкрософт или иным способом.
В таблице ниже приводится сравнительная характеристика возможностей, которые предоставляют веб-приложениям служба контроля доступа и Azure AD B2C. В целом Azure AD B2C — это, скорее всего, правильный выбор для переноса, если приложение ориентировано на пользователей или поддерживает большое количество разных типов учетных записей.
| Функция | Поддержка службы контроля доступа | Поддержка Azure AD B2C |
|---|---|---|
| Типы учетных записей | ||
| Рабочие и учебные учетные записи Майкрософт | Поддерживается | Поддерживаются через пользовательские политики |
| Учетные записи Windows Server Active Directory и AD FS | Поддерживаются через прямую федерацию с AD FS | Поддерживаются через федерации SAML с помощью настраиваемых политик |
| Учетные записи других корпоративных систем управления удостоверениями | Поддерживаются через прямую федерацию по протоколу WS-Federation | Поддерживаются через федерации SAML с помощью настраиваемых политик |
| Личные учетные записи Майкрософт | Поддерживается | Поддерживается |
| Учетные записи Facebook, Google, Yahoo | Поддерживается | Учетные записи Facebook и Google поддерживаются по умолчанию, Yahoo — через федерацию OpenID Connect с помощью настраиваемых политик |
| Совместимость с протоколами и пакетом SDK | ||
| Windows Identity Foundation | Поддерживается | Не поддерживается |
| WS-Federation | Поддерживается | Не поддерживается |
| OAuth 2.0 | Поддерживается черновая версия 13 | Поддерживается RFC 6749 (последняя спецификация) |
| WS-Trust | Поддерживается | Не поддерживается |
| Форматы маркеров | ||
| JWT | Поддерживается в бета-версии | Поддерживается |
| SAML 1.1 | Поддерживается | Не поддерживается |
| SAML 2.0 | Поддерживается | Не поддерживается |
| SWT | Поддерживается | Не поддерживается |
| Настройки | ||
| Настраиваемый пользовательский интерфейс обнаружения домашней области и выбора учетной записи | Загружаемый код, который можно включить в приложения | Возможность полной конфигурации пользовательского интерфейса через настраиваемые каскадные таблицы стилей |
| Передача пользовательских сертификатов для подписи маркера | Поддерживается | Настраиваемые ключи подписывания (не сертификаты) поддерживаются через пользовательские политики |
| Настройка утверждений в маркерах | — Отправка входящих утверждений от поставщиков удостоверений — Получение маркера доступа от поставщика удостоверений как утверждения — Выдача исходящих утверждений на основе значений входящих утверждений — Выдача исходящих утверждений с постоянными значениями |
— Может отправлять утверждения от поставщиков удостоверений; для некоторых утверждений требуются пользовательские политики — Не может получить маркер доступа от поставщика удостоверений как утверждение — Может выдавать исходящие утверждения на основе значений входящих утверждений через пользовательские политики — Может выдавать исходящие утверждения с постоянными значениями через пользовательские политики |
| Служба автоматизации | ||
| Автоматизация задач настройки и управления | Поддерживается через службу управления контролем доступа | — Создание пользователей, которым разрешено использование API-интерфейса Microsoft Graph — Не может программно создавать клиенты, приложения или политики B2C |
Если вы решите перенести свои приложения и службы в Azure AD B2C, сначала изучите следующие материалы:
- Документация по Azure AD B2C
- Пользовательские политики Azure AD B2C
- Цены на Azure Active Directory B2C
Перенос в Ping Identity или Auth0
В некоторых случаях может оказаться, что идентификатор Microsoft Entra и Azure AD B2C недостаточно для замены контроль доступа в веб-приложениях без внесения серьезных изменений в код. К некоторым распространенным примерам относятся следующие:
- веб-приложения, использующие WIF или WS-Federation для входа через поставщиков удостоверений социальных сетей, например Google или Facebook;
- веб-приложения, устанавливающие прямую федерацию с корпоративным поставщиком удостоверений по протоколу WS-Federation;
- веб-приложения, которым требуется маркер доступа, выданный поставщиком удостоверений социальных сетей (например, Google или Facebook), в качестве утверждения в токенах, выданных службой контроля доступа;
- Веб-приложения со сложными правилами преобразования маркеров, которые Microsoft Entra идентификатора или Azure AD B2C, не могут воспроизводиться.
- мультитенантные веб-приложения, использующие ACS для централизованного управления федерацией с многими различными поставщиками удостоверений.
В таких случаях рассмотрите возможность переноса веб-приложения в другую облачную службу проверки подлинности. Мы советуем изучить следующие варианты. Каждый из них предоставляет те же возможности, что и служба контроля доступа.
Auth0 — это гибкая облачная служба идентификации, поддерживающая почти все возможности ACS (для нее доступно общее руководство по переходу для клиентов службы контроля доступа).
Ping Identity предлагает два решения, аналогичные возможностям ACS. PingOne — это облачная служба идентификации, которая поддерживает многие из тех же функций, что и служба ACS. PingFederate представляет собой аналогичную службу идентификации в локальной среде, которая обеспечивает большую гибкость. Дополнительные сведения по их использованию см. в этом руководстве.
Мы работаем с Ping Identity и Auth0, чтобы гарантировать, что у всех клиентов службы контроля доступа есть пути переноса своих приложений и служб, которые позволяют уменьшить объем работы, необходимый для перемещения.
Веб-службы, использующие активную проверку подлинности
Для веб-служб, которые защищены с помощью маркеров, выпущенных службой контроля доступа, предлагаются следующие функции и возможности:
- Возможность зарегистрировать одно или несколько удостоверений службы в пространстве имен ACS. Удостоверения служб можно использовать для запроса маркеров.
- Поддержка запроса маркеров по протоколу OAuth WRAP и OAuth 2.0 (черновой вариант 13), используя следующие типы учетных данных:
- простой пароль, созданный для удостоверения службы;
- подписанный маркер SWT, использующий симметричный ключ или сертификат X509;
- маркер SAML, выданный доверенным поставщиком удостоверений (обычно это экземпляр ADFS).
- Поддержка маркеров следующих форматов: JWT, SAML 1.1, SAML 2.0 и SWT.
- Простые правила преобразования маркеров.
Удостоверения службы в ACS обычно позволяют реализовать проверку подлинности между серверами.
Переход на идентификатор Microsoft Entra
Мы рекомендуем для этого типа потока проверки подлинности перейти на Microsoft Entra id. Microsoft Entra id — это облачный поставщик удостоверений для рабочих или учебных учетных записей Майкрософт. Microsoft Entra ID — это поставщик удостоверений для Microsoft 365, Azure и многого другого.
Вы также можете использовать идентификатор Microsoft Entra для проверки подлинности между серверами с помощью реализации Microsoft Entra предоставления учетных данных клиента OAuth. В следующей таблице сравниваются возможности контроль доступа при проверке подлинности между серверами с возможностями, доступными в Microsoft Entra ID.
| Функция | Поддержка службы контроля доступа | Поддержка идентификаторов Microsoft Entra |
|---|---|---|
| Регистрация веб-службы | Создание проверяющей стороны на портале управления ACS | Создание веб-приложения Microsoft Entra в портал Azure |
| Регистрация клиента | Создание удостоверения службы на портале управления ACS | Создание другого веб-приложения Microsoft Entra в портал Azure |
| Используемый протокол | — Протокол OAuth WRAP — Предоставление учетных данных клиента OAuth 2.0 (черновой вариант 13) |
Предоставление учетных данных клиента OAuth 2.0 |
| Методы проверки подлинности клиента | — Простой пароль — Подписанный маркер SWT — Токен SAML из федеративного поставщика удостоверений |
— Простой пароль — Подписанный маркер JWT |
| Форматы маркеров | — JWT — SAML 1.1 — SAML 2.0 — SWT |
Только JWT |
| Преобразование маркеров | — Добавление пользовательских утверждений — Простая логика выдачи утверждения If-Then |
Добавление пользовательских утверждений |
| Автоматизация задач настройки и управления | Поддерживается через службу управления контролем доступа | Поддерживается с помощью API-интерфейса Microsoft Graph |
Рекомендации по реализации межсерверных сценариев см. в следующих источниках:
- Раздел "Между службами" руководства разработчика Microsoft Entra
- Calling web APIs in a daemon or long-running process (Вызов веб-API в длительном процессе или процессе с использованием управляющей программы)
- Authenticating to Azure AD in daemon apps with certificates (Проверка подлинности приложений управляющей программы в Azure AD с помощью сертификатов)
Перенос в Ping Identity или Auth0
В некоторых случаях может оказаться, что Microsoft Entra учетных данных клиента и реализации предоставления OAuth недостаточно для замены контроль доступа в архитектуре без серьезных изменений кода. К некоторым распространенным примерам относятся следующие:
- проверка подлинности между серверами с помощью токена в форматах, отличных от JWT;
- проверка подлинности между серверами с помощью входящего маркера, предоставленного внешним поставщиком удостоверений;
- Проверка подлинности между серверами с помощью правил преобразования маркеров, которые Microsoft Entra идентификатор не могут воспроизвести.
В таких случаях рассмотрите возможность переноса веб-приложения в другую облачную службу проверки подлинности. Мы советуем изучить следующие варианты. Каждый из них предоставляет те же возможности, что и служба контроля доступа.
Auth0 — это гибкая облачная служба идентификации, поддерживающая почти все возможности ACS (для нее доступно общее руководство по переходу для клиентов службы контроля доступа).
Ping Identity предоставляет два решения, аналогичные по возможностям ACS. PingOne — это облачная служба идентификации, которая поддерживает многие из тех же функций, что и служба ACS. PingFederate представляет собой аналогичную службу идентификации в локальной среде, которая обеспечивает большую гибкость. Дополнительные сведения по их использованию см. в этом руководстве.
Мы работаем с Ping Identity и Auth0, чтобы гарантировать, что у всех клиентов службы контроля доступа есть пути переноса своих приложений и служб, которые позволяют уменьшить объем работы, необходимый для перемещения.
Сквозная проверка подлинности
Для сквозной проверки подлинности с произвольным преобразованием токена нет эквивалентной технологии Майкрософт для ACS. Если это то, что нужно вашим клиентам, Auth0 может предоставить решения для наиболее точного приближения.
Вопросы, проблемы и отзывы
Мы понимаем, что сведения о переносе в этой статье подходят не всем, и некоторым клиентам ACS требуются советы и рекомендации по определению правильного плана. Если вы хотите обсудить сценарии переноса и связанные с этим процессом вопросы, оставьте комментарий на этой странице.