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

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

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

• Рабочие или учебные учетные записи, если сущность имеет учетную запись в идентификаторе Microsoft Entra
• Microsoft личная учетная запись (MSA) для всех, кто имеет учетную запись в Outlook.com, Hotmail, Live, Skype, Xbox и т. д.
• Внешние удостоверения в идентификаторе Microsoft Entra для партнеров (пользователи за пределами организации)
• Microsoft Entra Business to Customer (B2C), который позволяет создавать решение, которое позволяет клиентам использовать другие поставщики удостоверений. Приложения, использующие Azure AD B2C или подписанные на Microsoft Dynamics 365 защиты от мошенничества с Помощью Azure Active Directory B2C , могут оценить потенциально мошеннические действия после попыток создания новых учетных записей или входа в экосистему клиента.

Необходимой частью регистрации приложений в идентификаторе 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 — один клиент) можно разрешить только пользователям и гостям из клиента, где разработчик зарегистрировал свое приложение. Этот параметр является наиболее распространенным для бизнес-приложений.

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

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

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

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

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

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

Клиентские приложения

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

Azure AD B2C предоставляет идентификацию клиентов как услугу. Вы можете разрешить пользователям использовать имя пользователя и пароль только для приложения. B2C поддерживает клиентов с удостоверениями социальных удостоверений для уменьшения паролей. Вы можете поддерживать корпоративных клиентов, федеративный каталог Azure AD B2C с идентификатором Microsoft Entra или любым поставщиком удостоверений, поддерживающим язык разметки утверждений безопасности (SAML) для OpenID Connect. В отличие от мультитенантного приложения, ваше приложение не использует корпоративный каталог клиента, где они защищают свои корпоративные активы. Клиенты могут получить доступ к вашей службе или возможности, не предоставляя приложению доступ к корпоративным ресурсам.

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

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

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

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

Анимированный GIF-файл показывает две схемы с переходом движения между первой схемой и второй схемой. Заголовок первой схемы: субъект-служба автоматически создается в клиенте, когда первый пользователь из клиента проходит проверку подлинности в приложении. Второй заголовок схемы: администратор клиента управляет работой приложения в клиенте с приложением Enterprise для этого приложения.

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

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

Мультитенантные приложения войдите пользователей из домашнего клиента пользователя, когда приложение использует общую или конечную точку организации. Приложение имеет одну регистрацию приложения, как показано на следующей схеме. В этом примере приложение регистрируется в клиенте Adatum. Пользователь A из Adatum и User B из Contoso может войти в приложение с ожиданием User 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 Business to Business (B2B). Как показано на следующей схеме, предприятия могут приглашать пользователей стать гостевыми пользователями в клиенте. После того как пользователь принимает приглашение, он может получить доступ к данным, защищенным приглашенным клиентом. Пользователь не создает отдельные учетные данные в клиенте.

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

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

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

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

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

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