Сценарий. Использование идентификатора Microsoft Entra для защиты доступа к платформам и приложениям SAP

Этот документ содержит рекомендации по техническому проектированию и настройке платформ SAP и приложений при использовании идентификатора Microsoft Entra в качестве основной службы проверки подлинности пользователей для облачных удостоверений SAP. Облачные службы удостоверений SAP включают проверку подлинности, подготовку удостоверений, каталог удостоверений и управление авторизацией. Дополнительные сведения о начальной настройке проверки подлинности в интеграции единого входа (SSO) Microsoft Entra с SAP Cloud Identity Services. Дополнительные сведения о подготовке и других сценариях см . в плане развертывания Microsoft Entra для подготовки пользователей с помощью источника SAP и целевых приложений и управления доступом к приложениям SAP.

Термины, употребляемые в этом руководстве

Обзор

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

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

• Вы хотите централизованно управлять всеми удостоверениями и только из идентификатора Microsoft Entra.
• Вы хотите максимально сократить усилия на обслуживание и автоматизировать проверку подлинности и доступ к приложениям в Майкрософт и SAP.
• Общие рекомендации по идентификатору Microsoft Entra с IAS применяются для приложений, развернутых в приложениях BTP и SAP SaaS, настроенных в IAS. Также будут предоставлены конкретные рекомендации, применимые к BTP (например, использование сопоставлений ролей с группами Microsoft Entra) и приложений SAP SaaS (например, использование службы подготовки удостоверений для авторизации на основе ролей).
• Мы также предполагаем, что пользователи уже подготовлены в идентификаторе Microsoft Entra и в отношении любых систем SAP, требующих подготовки пользователей к работе. Независимо от того, как это было достигнуто: подготовка могла выполняться вручную, от локальная служба Active Directory через Microsoft Entra Подключение или через системы управления персоналом, такие как SAP SuccessFactors. Поэтому в этом документе SuccessFactors считается приложением, куда будут входить (существующие) пользователи. Мы не охватываем фактическую подготовку пользователей из SuccessFactors в идентификатор Microsoft Entra. Дополнительные сведения о переносе пользователей в идентификатор Microsoft Entra для использования с рабочими нагрузками SAP см . в плане развертывания Microsoft Entra для подготовки пользователей с помощью источника SAP и целевых приложений и управления доступом к приложениям SAP.

Основываясь на этих предположениях, мы уделим особое внимание продуктам и службам, представленным на приведенной ниже схеме. Это различные компоненты, которые являются наиболее важными для проверки подлинности и авторизации в облачной среде.

Если вы использовали SAP Identity Management (IDM), можно перенести сценарии управления удостоверениями из SAP IDM в Microsoft Entra. Дополнительные сведения см. в статье "Миграция сценариев управления удостоверениями" из SAP IDM в Microsoft Entra.

Рекомендации

Итоги

• 1. Использование федеративной проверки подлинности на SAP Business Technology Platform, а также использование приложений SaaS SAP с помощью службы SAP Identity Authentication
• 2. Использование идентификатора Microsoft Entra для проверки подлинности и IAS/BTP для авторизации
• 3. Использование групп Microsoft Entra для авторизации с помощью коллекций ролей в IAS/BTP
• 4. Использование одной вспомогательной учетной записи BTP только для приложений, имеющих аналогичные требования к удостоверениям
• 5. Использование рабочего арендатора IAS для проверки подлинности и авторизации пользователя
• 6. Определение процесса для переключения сертификатов для подписи SAML

1. Использование федеративной проверки подлинности на SAP Business Technology Platform, а также использование приложений SaaS SAP с помощью службы SAP Identity Authentication

Контекст

Ваши приложения в BTP могут пользоваться поставщиками удостоверений с помощью конфигураций доверия для проверки подлинности пользователей с использованием протокола SAML 2.0 между BTP/XSUAA и поставщиком удостоверений. Обратите внимание, что поддерживается только SAML версии 2.0, хотя между самим приложением и BTP/XSUAA используется протокол OpenID Connect (не относится к этому контексту).

В BTP можно настроить конфигурацию доверия для sap Cloud Identity Services — identity Authentication (это по умолчанию), но если ваш доверенный каталог пользователя — это идентификатор Microsoft Entra, можно настроить федерацию , чтобы пользователи могли войти с помощью существующих учетных записей Microsoft Entra.

На вершине федерации можно также настроить подготовку пользователей, чтобы пользователи Microsoft Entra были подготовлены заранее в BTP. Однако для этого нет собственной поддержки (только для идентификатора Microsoft Entra —> SAP Identity Authentication Service). Интегрированное решение с собственной поддержкой будет службой подготовки удостоверений BTP. Подготовка учетных записей пользователей может понадобиться для авторизации (например, для добавления пользователей к ролям). Однако в зависимости от требований вы также можете достичь этого с помощью групп Microsoft Entra (см. ниже), что может означать, что вам вообще не нужна подготовка пользователей.

При настройке связи федерации существует несколько вариантов:

• Вы можете выбрать федерацию для идентификатора Microsoft Entra непосредственно из BTP/XSUAA.
• Вы можете настроить федерацию с IAS, которая, в свою очередь, настроена для федерации с идентификатором Microsoft Entra в качестве поставщика корпоративных удостоверений (также известного как "Проксиинг SAML").

Для приложений SaaS SAP служба IAS проходит подготовку и предварительную настройку для упрощения подключения пользователей. (Примеры этого: SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud и другие.) Этот сценарий менее сложный, так как IAS напрямую связан с целевым приложением и не связан с XSUAA. В любом случае для этой установки применяются те же правила, что и для идентификатора Microsoft Entra с IAS в целом.

Наши рекомендации

Если ваш доверенный каталог пользователя является идентификатором Microsoft Entra, рекомендуется настроить конфигурацию доверия в BTP для IAS. IAS, в свою очередь, настраивается для федерации с идентификатором Microsoft Entra в качестве поставщика корпоративных удостоверений.

В конфигурации доверия в BTP мы рекомендуем включить параметр "Создание теневых пользователей при входе в систему". Таким образом, пользователи, которые еще не были созданы в BTP, автоматически получают учетную запись при входе через IAS / Идентификатор Microsoft Entra впервые. Если этот параметр будет отключен, только предварительно подготовленные пользователи смогут выполнять вход.

Для чего эта рекомендация?

При использовании федерации можно определить конфигурацию доверия на уровне вспомогательной учетной записи BTP. В этом случае необходимо повторить конфигурацию для всех остальных вспомогательных учетных записей, которые вы используете. Используя IAS в качестве промежуточной конфигурации доверия, вы получаете преимущества от централизованной конфигурации нескольких вспомогательных учетных записей, а также вы можете пользоваться такими функциями IAS, как проверка подлинности на основе рисков и централизованное обогащение атрибутов утверждений. Для защиты пользовательского интерфейса эти расширенные функции безопасности следует применять только в одном расположении. Это может быть IAS или при сохранении идентификатора Microsoft Entra в качестве единого авторитетного хранилища пользователей (как и в локальной среде этого документа), это будет централизованно обрабатываться управлением условным доступом Microsoft Entra.

Примечание. Для IAS каждая вспомогательная учетная запись считается "приложением", хотя в этой учетной записи может быть развернуто одно или несколько приложений. В IAS каждое такое приложение можно настроить для федерации с тем же поставщиком корпоративных удостоверений (идентификатор Microsoft Entra в данном случае).

Сводка по реализации

В идентификаторе Microsoft Entra:

• При необходимости настройте идентификатор Microsoft Entra для простого единого входа (Простой единый вход), который автоматически выполняет вход пользователей, когда они находятся на корпоративных устройствах, подключенных к корпоративной сети. Если он включен, пользователям не нужно вводить пароль для входа в Microsoft Entra ID, а в большинстве случаев — даже вводить имя пользователя.

В идентификаторе Microsoft Entra и IAS:

• Следуйте документации по подключению идентификатора Microsoft Entra к IAS в режиме федерации (прокси-сервер) (документация SAP, документация Майкрософт). Следите за настройкой NameID единого входа в идентификаторе Microsoft Entra ID, так как имена участника-пользователя не обязательно являются адресами электронной почты.
• Настройте пакетное приложение для использования идентификатора Microsoft Entra, перейдя на страницу "Условная проверка подлинности" и установив параметр "Поставщик удостоверений по умолчанию" поставщику корпоративных удостоверений, представляющего каталог Microsoft Entra.

В BTP:

• Настройте конфигурацию доверия для IAS (документ SAP) и убедитесь, что параметры "Доступно для входа пользователя" и "Создание теневых пользователей при входе в систему" включены.
• При необходимости отключите параметр "Доступный для входа пользователя" в конфигурации доверия sap ID Service, чтобы пользователи всегда проверяли подлинность через идентификатор Microsoft Entra и не отображались на экране, чтобы выбрать поставщика удостоверений.

2. Использование идентификатора Microsoft Entra для проверки подлинности и IAS/BTP для авторизации

Контекст

Когда BTP и IAS были настроены для проверки подлинности пользователей через федерацию по идентификатору Microsoft Entra ID, существует несколько вариантов настройки авторизации:

• В идентификаторе Microsoft Entra можно назначить пользователей и групп Microsoft Entra корпоративным приложениям, представляющим экземпляр SAP IAS в идентификаторе Microsoft Entra ID.
• В службе IAS можно использовать проверку подлинности на основе рисков, чтобы разрешить или заблокировать вход и ограничить доступ к приложению в BTP.
• В этом случае можно использовать коллекции ролей для определения пользователей и групп, которые могут иметь доступ к приложению и получать определенные роли.

Наши рекомендации

Рекомендуется не помещать авторизацию непосредственно в сам Microsoft Entra и явно отключить "Обязательное назначение пользователей" в корпоративном приложении в идентификаторе Microsoft Entra ID. Обратите внимание, что для приложений SAML этот параметр включен по умолчанию, поэтому, чтобы его отключить, необходимо выполнить явное действие.

Для чего эта рекомендация?

Когда приложение федеративно через IAS, с точки зрения идентификатора Microsoft Entra, пользователь по сути "выполняет проверку подлинности в IAS" во время входа. Это означает, что идентификатор Microsoft Entra не содержит сведений о том, в каком окончательном приложении BTP пользователь пытается войти в систему. Это также означает, что авторизация в идентификаторе Microsoft Entra может использоваться только для выполнения очень грубой авторизации, например, позволяя пользователю входить в любое приложение в BTP или нет. Это также подчеркивает стратегию SAP, направленную на изоляцию приложений и механизмов проверки подлинности на уровне вспомогательной учетной записи BTP.

Хотя это может быть допустимой причиной использования "Обязательное назначение пользователей", это означает, что в настоящее время существует два разных места, где необходимо поддерживать сведения об авторизации: как в идентификаторе Microsoft Entra в корпоративном приложении (где оно применяется ко всем приложениям BTP), так и в каждом подсчете BTP. Это может привести к путанице и неправильным настройкам, когда параметры авторизации обновляются в одном месте, а не в другом. Например, пользователь был разрешен в BTP, но не назначен приложению в идентификаторе Microsoft Entra, что привело к сбою проверки подлинности.

Сводка по реализации

В приложении Microsoft Entra Enterprise, представляющего отношение федерации с IAS, отключите "Обязательное назначение пользователей". Это также означает, что вы можете пропустить шаг назначения пользователей.

3. Использование групп Microsoft Entra для авторизации с помощью коллекций ролей в IAS/BTP

Контекст

Существует несколько вариантов авторизации приложений BTP:

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

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

Наши рекомендации

Если вы хотите использовать идентификатор Microsoft Entra в качестве авторитетного источника для точной авторизации, рекомендуется использовать группы Microsoft Entra и назначать их коллекциям ролей в BTP. Предоставление пользователям доступа к определенным приложениям, а затем просто означает добавление их в соответствующие группы Microsoft Entra без дополнительной настройки в IAS/BTP.

В этой конфигурации рекомендуется использовать идентификатор группы Microsoft Entra (идентификатор объекта) в качестве уникального идентификатора группы, а не отображаемого имени (sAMAccountName). Это означает, что идентификатор группы должен использоваться в качестве утверждения "Группы" в токене SAML, выданном идентификатором Microsoft Entra. Кроме того, идентификатор группы используется для назначения коллекции ролей в BTP.

Для чего эта рекомендация?

Если вы назначите пользователей непосредственно коллекциям ролей в BTP, вы не будете централизованно принимать решения о авторизации в идентификаторе Microsoft Entra. Это также означает, что пользователь уже должен существовать в службе IAS до того, как он может быть назначен коллекции ролей в BTP, так что при этом мы рекомендуем использовать федерацию вместо подготовки пользователей. То есть теневая учетная запись пользователя может еще не существовать в службе IAS тогда, когда вы хотите назначить пользователя. Использование групп Microsoft Entra и назначение их коллекциям ролей устраняет эти проблемы.

Назначение групп коллекциям ролей может противоречить предыдущей рекомендации, чтобы не использовать идентификатор Microsoft Entra для авторизации. Даже в этом случае решение авторизации по-прежнему принимается в BTP, это просто то, что решение теперь основано на членстве в группах, поддерживаемых в идентификаторе Microsoft Entra.

Мы рекомендуем использовать идентификатор группы Microsoft Entra, а не его имя, так как идентификатор группы является глобально уникальным, неизменяемым и никогда не может повторно использоваться для другой группы позже; в то время как использование имени группы может привести к проблемам при изменении имени, и возникает риск безопасности при удалении группы, а другой — с тем же именем, но с пользователями, у которых нет доступа к приложению.

Сводка по реализации

В идентификаторе Microsoft Entra:

• Создайте группы, в которые можно добавить пользователей, которым требуется доступ к приложениям в BTP (например, создайте группу Microsoft Entra для каждой коллекции ролей в BTP).
• В приложении Microsoft Entra Enterprise, представляющего отношение федерации с IAS, настройте атрибуты пользователя SAML и утверждения, чтобы добавить утверждение группы безопасности:

  • Присвойте атрибуту "Источник" значение "Идентификатор группы" и имя Groups (точно такое же написание, с прописной "G").

  • Кроме того, чтобы сохранить полезные данные утверждений небольшими и избежать выполнения ограничения, поэтому идентификатор Microsoft Entra ограничивает количество утверждений группы до 150 в утверждениях SAML, настоятельно рекомендуется ограничить группы, возвращаемые в утверждениях, только те группы, которые явно были назначены:

    • В разделе "Какие группы, связанные с пользователем, должны быть возвращены в утверждении?" ответ с сообщением "Группы, назначенные приложению". Затем для групп, которые необходимо включить в качестве утверждений, назначьте их корпоративному приложению с помощью раздела "Пользователи и группы" и выберите "Добавить пользователя или группу".

    

В IAS:

• В конфигурации поставщика корпоративных удостоверений в параметрах федерации удостоверений убедитесь, что вы отключите "Использовать хранилище пользователей проверки подлинности удостоверений"; в противном случае сведения о группе из идентификатора Microsoft Entra ID не будут сохранены в токене SAML по отношению к BTP и авторизации завершится ошибкой.

В BTP:

• В коллекциях ролей, используемых приложениями в этом подсчете, сопоставляйте коллекции ролей с группами пользователей, добавив конфигурацию поставщика удостоверений IAS и задав имя идентификатору группы (идентификатор объекта) группы Microsoft Entra.

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

Контекст

В рамках BTP каждая вспомогательная учетная запись может содержать несколько приложений. Тем не менее с перспективы IAS "Объединенное в пакет приложение" — это полная вспомогательная учетная запись BTP, а не более детализированные приложения в ней. Это означает, что все параметры доверия, проверка подлинности и конфигурация доступа, а также параметры фирменной символики и макета в IAS применяются ко всем приложениям в этой вспомогательной учетной записи. Аналогично все конфигурации доверия и коллекции ролей в BTP также применяются ко всем приложениям в этой вспомогательной учетной записи.

Наши рекомендации

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

Для чего эта рекомендация?

Объединяя несколько приложений, которые имеют очень разные требования к удостоверениям, в одну вспомогательную учетную запись BTP, у вас может оказаться конфигурация, которая является небезопасной или для которой легко выполнить неправильную настройку. Например, изменение конфигурации для общего ресурса, например поставщика удостоверений, одного приложения в BTP влияет на все приложения, использующие этот общий ресурс.

Сводка по реализации

Тщательно обдумайте способ группировки приложений во вспомогательных учетных записях в BTP. Дополнительные сведения см. в документации по модели учетной записи SAP.

5. Использование рабочего арендатора IAS для проверки подлинности и авторизации пользователя

Контекст

При работе с IAS обычно имеется рабочий арендатор и арендатор для разработки и тестирования. Для разных вспомогательных учетных записей или приложений в BTP можно выбрать, какой поставщик удостоверений (арендатор IAS) использовать.

Наши рекомендации

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

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

Для чего эта рекомендация?

Так как IAS является централизованным компонентом, настроенным для федерации с идентификатором Microsoft Entra, существует только одно место, где должна быть настроена и поддерживается конфигурация федерации и удостоверения. Дедупликация этого в других клиентах IAS может привести к неправильной настройке или несоответствиям в доступе конечных пользователей между средами.

6. Определение процесса для переключения сертификатов для подписи SAML

Контекст

При настройке федерации между идентификатором Microsoft Entra и IAS, а также между IAS и BTP метаданные SAML обмениваются, содержащие сертификаты X.509, используемые для шифрования и криптографических подписей токенов SAML, отправляемых между обеими сторонами. Эти сертификаты имеют даты окончания срока действия и должны периодически обновляться (даже в экстренных ситуациях, например, когда сертификат был скомпрометирован).

Примечание. Срок действия исходного сертификата Microsoft Entra, используемый для подписывания утверждений SAML, составляет 3 года (и обратите внимание, что сертификат относится к корпоративному приложению, в отличие от токенов OpenID Подключение и OAuth 2.0, подписанных глобальным сертификатом в идентификаторе Microsoft Entra ID). Вы можете создать новый сертификат с другим сроком действия или создать и импортировать свой собственный сертификат.

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

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

Однако IAS позволяет настроить только поставщиков корпоративных удостоверений с помощью импорта XML-файла метаданных, он не поддерживает конечную точку метаданных для динамического получения метаданных Microsoft Entra (например https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Аналогичным образом BTP не позволяет настроить новую конфигурацию доверия из конечной точки метаданных IAS (например, https://my-ias-tenant.accounts.ondemand.com/saml2/metadata). Кроме этого, ему требуется одна отправка метаданных в формате XML-файла.

Наши рекомендации

При настройке федерации удостоверений между любыми двумя системами (например, идентификаторОм Microsoft Entra и IAS, А также IAS и BTP) убедитесь, что вы фиксируете дату окончания срока действия используемых сертификатов. Убедитесь в том, что эти сертификаты можно заменить заранее, а также в существовании документированного процесса обновления новых метаданных во всех проверяющих сторонах, зависящих от этих сертификатов.

Как описано ранее, мы рекомендуем настроить конфигурацию доверия в BTP для IAS, которая, в свою очередь, настроена для федерации с Идентификатором Microsoft Entra в качестве поставщика корпоративных удостоверений. В этом случае важны следующие сертификаты (используемые для подписи и шифрования SAML):

• Сертификат вспомогательной учетной записи BTP. При этом изменении необходимо обновить конфигурацию SAML 2.0 для приложения в IAS.
• Сертификат клиента в IAS: когда это изменяется, необходимо обновить конфигурацию SAML 2.0 корпоративного приложения в идентификаторе Microsoft Entra ID и конфигурацию доверия в BTP.
• Сертификат корпоративного приложения в идентификаторе Microsoft Entra: при этом необходимо обновить конфигурацию поставщика корпоративных удостоверений SAML 2.0 в IAS.

В SAP есть примеры реализаций для уведомлений о сертификатах клиента с помощью SAP Cloud Integration и обработки почти с истекающим сроком действия. Их можно адаптировать с помощью Azure Integration Services или PowerAutomate. Но они должны быть адаптированы для работы с сертификатами сервера. Для такого подхода требуется пользовательская реализация.

Для чего эта рекомендация?

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

Сводка по реализации

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

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

Использование Azure AD B2C в качестве поставщика удостоверений

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

Но есть несколько важных отличий. Настройка Azure AD B2C в качестве поставщика корпоративных удостоверений в IAS и настройка федерации между обоими клиентами подробно описана в этой записи блога.

Регистрация приложения SAML в Azure AD B2C

В Azure AD B2C нет коллекции корпоративных приложений, которую можно использовать для простой настройки отношений доверия с корпоративным поставщиком удостоверений в IAS. Вместо этого вам придется использовать пользовательские политики для регистрации приложения SAML в Azure AD B2C. Это приложение SAML играет ту же логическую роль, что и корпоративное приложение в идентификаторе Microsoft Entra ID, поэтому то же руководство по перемещению сертификатов SAML применяется, например.

Авторизация с помощью Azure AD B2C

Azure AD B2C изначально не поддерживает использование групп для создания коллекций пользователей, которым можно назначить доступ, что означает, что руководство по использованию групп Microsoft Entra для авторизации через коллекции ролей в BTP должно быть реализовано по-другому.

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

Независимо от того, откуда берутся данные авторизации, впоследствии их можно отображать как атрибут Groups внутри токена SAML, настроив имя этого атрибута в качестве типа утверждения партнера по умолчанию для схемы утверждений или переопределив тип утверждения партнера в выходных утверждениях. Обратите внимание, что BTP позволяет сопоставлять коллекции ролей с атрибутами пользователей. Это означает, что для принятия решений об авторизации можно использовать любое имя атрибута, даже если вы не используете имя атрибута Groups.

Next Steps

• Дополнительные сведения о начальной настройке в этом руководстве
• планирование развертывания Microsoft Entra для подготовки пользователей с помощью источника SAP и целевых приложений и
• управление доступом к приложениям SAP
• Узнайте о дополнительных сценариях интеграции SAP с идентификатором Microsoft Entra и более познакомьтесь с ним