Типы идентификаций и учетных записей для одно- и мультитенантных приложений

В этой статье объясняется, как разработчик может выбрать, разрешено ли ваше приложение только пользователям из клиента Microsoft Entra, любого клиента Microsoft Entra или пользователей с личными учетными записями Майкрософт. Приложение можно настроить как однопользовательское или многопользовательское во время регистрации приложения в Microsoft Entra. Убедитесь, что принцип "Нулевое доверие" для доступа с минимальными привилегиями позволяет приложению запрашивать только необходимые разрешения.

Платформа удостоверений Майкрософт обеспечивает поддержку определенных типов удостоверений:

• Рабочие или учебные учетные записи, если у организации есть учетная запись в системе идентификации Microsoft Entra ID.
• Microsoft личные учетные записи (MSA) для всех, у кого есть учетная запись в Outlook.com, Hotmail, Live, Skype, Xbox и т. д.
• Внешние удостоверения в Microsoft Entra ID для партнеров (пользователи за пределами вашей организации).

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

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

• Accounts in this organizational directory only (O365 only - Single tenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

Учетные записи только в этом каталоге организации — один арендатор

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

Учетные записи только в каталогах любых организаций — мультитенантные

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

Учетные записи в любой учетной записи организации и личных учетных записях Майкрософт

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

Только личные учетные записи Майкрософт

При выборе только личных учетных записей Майкрософт вы разрешаете использовать приложение только пользователям с учетными записями потребителей.

Это не только ответственность разработчика

Хотя вы в регистрации приложения указываете, кто может входить в ваше приложение, последнее слово остается за отдельным пользователем или администраторами его домашней организации. Администраторы клиентов часто хотят иметь больше контроля над приложением, чем только кто может войти. Например, им может потребоваться применить политику условного доступа к приложению или управлять группой, которую они позволяют использовать приложение. Чтобы администраторы клиентов могли иметь этот элемент управления, в платформе удостоверений Microsoft есть второй объект: приложение для корпоративных клиентов. Корпоративные приложения также называются субъектами-службами.

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

Поддерживаемые типы учетных записей включают вариант учетные записи из любого каталога организаций для мультитенантного приложения, чтобы позволить пользователям из организационных каталогов его использовать. Другими словами, вы позволяете пользователю войти в ваше приложение, используя их собственные учетные данные из любой учётной записи Microsoft Entra. Субъект-служба автоматически создается в клиенте, когда первый пользователь из клиента проходит проверку подлинности в приложении.

Существует только одна регистрация приложения или один объект приложения. Однако в каждом арендаторе есть корпоративное приложение или учетная запись службы (SP), позволяющие пользователям входить в приложение. Администратор клиента может контролировать работу приложения в клиенте.

Рекомендации по мультитенантным приложениям

Мультитенантные приложения осуществляют вход для пользователей из домашнего клиента, когда приложение использует общий или организационный конечный пункт доступа. Приложение имеет одну регистрацию приложения, как показано на следующей схеме. В этом примере приложение регистрируется в клиенте Adatum. Пользователь A из Adatum и пользователь B из Contoso могут войти в приложение с ожиданием, что пользователь A из Adatum будет обращаться к данным Adatum, а пользователь B из Contoso будет обращаться к данным Contoso.

Название схемы: мультитенантное приложение и внешние удостоверения, также известные как B2 B.

В качестве разработчика вы несете ответственность за разделение сведений о клиенте. Например, если данные Contoso из Microsoft Graph, пользователь B из Contoso видит только данные Microsoft Graph компании Contoso. Нет возможности для пользователя B из Компании Contoso получить доступ к данным Microsoft Graph в клиенте Adatum, так как Microsoft 365 имеет истинное разделение данных.

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

Следующие шаги

• Как и почему приложения добавляются в идентификатор Microsoft Entra ID , объясняется, как объекты приложений описывают приложение с идентификатором Microsoft Entra.
• Рекомендации по обеспечению безопасности свойств приложений в идентификаторе Microsoft Entra охватывают такие свойства , как URI перенаправления, маркеры доступа, сертификаты и секреты, URI идентификатора приложения и владение приложением.
• Создание приложений с использованием подхода "Нулевое доверие" к удостоверениям предоставляет общие сведения о разрешениях и рекомендациях по доступу.
• Получение авторизации для доступа к ресурсам помогает понять, как лучше всего обеспечить нулевое доверие при получении разрешений доступа к ресурсам для приложения.
• Разработка стратегии делегированных разрешений помогает реализовать оптимальный подход к управлению разрешениями в приложении и разработке с помощью принципов нулевого доверия.
• Стратегия разрешений приложений помогает вам определиться с подходом к управлению учетными данными ваших приложений.