Предоставление идентификационных данных (или предоставление учетных записей ) — это процесс настройки учетных записей и установления соединений между тремя системами, в которых хранятся данные пользователей, а в некоторых случаях и установление соединений между пользователями и их устройствами.
В корпоративной среде Android информацию об учетных записях пользователей хранят три различные системы:
- Каталог пользователей организации является окончательным источником информации о пользователях.
- Вы (поставщик решения EMM) должны вести как минимум минимальный каталог пользователей организации.
- Google хранит некоторую информацию об управляемых аккаунтах Google Play и учетных записях Google для обеспечения управления приложениями через Google Play.
Ресурс Users представляет собой учётную запись, связанную с предприятием. Учётная запись может быть привязана к устройству или к пользователю, имеющему несколько устройств и использующему её на всех. Учётная запись может предоставлять доступ только к корпоративному Google Play или к другим сервисам Google, в зависимости от настроек предприятия вашего клиента :
Управляемые учётные записи Google — это существующие учётные записи, управляемые Google. Для этих учётных записей клиенту необходимо либо использовать Google в качестве поставщика удостоверений, либо подключить каталог пользователей своей организации к Google. Для предприятий, использующих управляемые учётные записи Google, Google отвечает за аутентификацию пользователя при подготовке устройства.
Управляемые аккаунты Google Play позволяют предприятиям автоматически создавать ограниченные учётные записи пользователей через своего поставщика решений для управления корпоративной мобильностью (EMM). Эти учётные записи предоставляют доступ только к управляемому Google Play. EMM несёт полную ответственность за аутентификацию пользователя при необходимости. Для предприятий с управляемыми аккаунтами Google Play это единственный доступный тип учётной записи.
Таблица 1: Поля и методы API пользователей
| управляемые аккаунты Google Play | управляемые аккаунты Google | |
|---|---|---|
| Поле | ||
| идентификатор | ||
| добрый | ||
| идентификатор_аккаунта | Уникальный идентификатор, который вы создаёте и сопоставляете с идентификатором ( userId ), возвращаемым Google Play. Не используйте персональные данные (PII). | Не установлено. |
| Тип учетной записи | deviceAccount, userAccount | учетная запись пользователя |
| отображаемое имя | Имя, которое вы отображаете в элементах пользовательского интерфейса, например, в Google Play. Не используйте персональные данные. | Не установлено. |
| Тип управления | emmManaged | googleManaged, emmManaged |
| основной адрес электронной почты | Не установлено. | Это поле является первичным ключом, с помощью которого вы управляете синхронизацией учетных записей доменов, управляемых Google, с учетными записями пользователей в вашей системе. |
| Методы | ||
| удалить | ||
| generateAuthenticationToken | ||
| generateToken | ||
| получать | ||
| getAvailableProductSet | ||
| вставлять | ||
| список | ||
| revokeToken | ||
| setAvailableProductSet | ||
| обновлять | ||
В рамках улучшений в регистрации устройств мы переходим на использование управляемых учетных записей Google для всех устройств Android Enterprise, используемых сотрудником с корпоративным идентификатором.
Для новых регистраций мы теперь рекомендуем использовать управляемые аккаунты Google вместо управляемых аккаунтов Google Play. Хотя мы продолжаем поддерживать управляемые аккаунты Google Play для существующих пользователей, они предоставляют только доступ к управляемому магазину Google Play. Управляемые аккаунты Google предоставляют пользователям доступ ко всему набору сервисов Google и кроссплатформенным функциям.
Улучшения в регистрации
Управляемые аккаунты Google позволяют идентифицировать пользователя в Google. Это обеспечивает взаимодействие между устройствами, например, передачу задач, уведомления и обмен информацией поблизости. Эти функции приобретают всё большую важность в корпоративной среде, где пользователи часто используют несколько устройств.
Предприятиям, не использующим Google в качестве поставщика удостоверений, теперь настоятельно рекомендуется подключить своего существующего поставщика удостоверений к Google. Это позволит создавать управляемые учётные записи Google для сотрудников в процессе привязки. Для этого предприятиям следует использовать того же поставщика удостоверений, который они используют для своей EMM.
Мы внесли следующие изменения:
Аутентификация конечного пользователя при регистрации устройства теперь выполняется Google/Android. Контроллер политики устройств (DPC) EMM требует, чтобы Android аутентифицировал пользователя в соответствующей точке, а затем Android возвращает DPC идентификационные данные вошедшего в систему пользователя.
При запросе аутентификации пользователя EMM должен передать Android токен регистрации. Этот токен возвращается API-вызовом к Android Enterprise и может быть закодирован в QR-коде, NFC-коде или полезной нагрузке для регистрации без касания.
Хотя Android теперь выполняет аутентификацию и предоставляет идентификационные данные пользователя в EMM, EMM по-прежнему отвечает за сопоставление идентификационных данных пользователя с правильной группой или организационной структурой. Это сопоставление необходимо для применения соответствующих политик к устройству. Поэтому предприятиям необходимо продолжать связывать каталог пользователей своей организации с EMM.
ИТ-администраторы могут включить или отключить новую функцию аутентификации конечных пользователей, предоставляемую Google. Чтобы обеспечить пользователям наилучший опыт работы, включая кросс-платформенные функции, мы рекомендуем ИТ-администраторам связать каталог пользователей своей организации с Google. Без этой связи пользователи будут управлять аккаунтами Google Play и не будут иметь доступа к кросс-платформенным функциям.
Новое требование ко всем EMM — предоставление дополнительной информации при создании токенов регистрации и входа. В частности, теперь необходимо указывать, является ли устройство беспользовательским (например, киоск или выделенное устройство) или нет.
Преимущества
Новый процесс предлагает следующие ключевые улучшения:
Упрощенная регистрация: сокращает количество ручных действий и сложность по сравнению со стандартными методами.
Поддержка учётных записей Google: теперь вы можете использовать учётные записи Google со всеми способами подготовки. Это устраняет необходимость в управляемых учётных записях Google Play.
Расширенные возможности для пользователей: с помощью управляемых учетных записей Google вы получаете расширенные возможности Android, включающие мощные функции для разных устройств, такие как совместное использование и копирование-вставка.
Реализация учетных записей пользователей
Чтобы узнать, как продолжить этот новый процесс регистрации, ознакомьтесь с разделом Реализация учетных записей пользователей .
Жизненный цикл управляемых аккаунтов Google
Для организаций, использующих учётные записи Google, учётные записи пользователей в решении EMM дублируют существующие учётные записи, связанные с другими сервисами Google (например, Google Workspace). Эти учётные записи относятся googleManaged ( таблица 1 ), поскольку внутренние службы Google являются источником создания учётной записи и информации о ней.
Как EMM, вы можете реализовать в своей консоли механизмы для упрощения создания и постоянной синхронизации учётных записей пользователей, хранящихся в вашей системе, с источниками учётных записей доменов Google, используя такие инструменты, как Google Cloud Directory Sync (GCDS) и Google Admin SDK Directory API . Обзор различных подходов см. здесь. Модель идентификации домена, управляемого Google, требует, чтобы учётная запись пользователя существовала в контексте вашего решения (консоль EMM, сервер EMM, возможно, в хранилище данных) до её подготовки на любом устройстве пользователя в контексте рабочего профиля.
В процессе подготовки идентификационных данных домен организации, управляемый Google, заполняется учётными записями пользователей. В некоторых случаях существующие онлайн-идентификационные данные пользователей (например, учётные записи Microsoft Exchange) синхронизируются с их учётными записями Google.
Синхронизация учетных записей клиентов
При развертывании аккаунтов Google организация может использовать инструмент GCDS для синхронизации данных в домене G Suite с данными в каталоге LDAP. Кроме того, вы можете использовать GCDS от имени организации, если она предоставит вам доступ.
Инструмент GCDS вызывает API Google Directory и синхронизирует имена пользователей, но не пароли.
Если организация использует Microsoft Active Directory и хочет синхронизировать пароли пользователей G Suite с их паролями Active Directory, то они (или вы) можете использовать инструмент синхронизации паролей G Suite (GSPS) с GCDS.
Инструкции по использованию GCDS для администраторов см. в статье Подготовка домена G Suite к синхронизации .
API каталога Google
При развертывании учетных записей Google вы можете использовать API каталогов Google для синхронизации активных каталогов, паролей или и того, и другого:
Использование API каталога для синхронизации только каталога. Если у вас есть доступ только для чтения к управляемому домену Google организации, вы можете использовать API каталога Google для получения информации об учётных записях Google, например, об именах пользователей (но не паролях). Поскольку вы не можете записывать данные в учётные записи Google пользователей, организация несёт полную ответственность за жизненный цикл учётных записей.
Сценарий 1 и сценарии аутентификации SSO на основе SAML описывают эту ситуацию более полно.
Информацию об использовании API каталога таким способом см. в разделе Извлечение всех пользователей учетной записи в документации API каталога.
Использование API каталога для синхронизации каталогов и, при необходимости, паролей. Если у вас есть доступ на чтение и запись к управляемому домену Google организации, вы можете использовать API каталога Google для получения имён пользователей, паролей и другой информации об учётных записях Google. Вы можете обновлять эту информацию и синхронизировать её со своей базой данных, а также нести полную или частичную ответственность за жизненный цикл учётных записей в зависимости от решения, которое вы предлагаете своим клиентам.
Сценарий 2 описывает эту ситуацию более полно.
Дополнительную информацию об использовании API каталога для управления информацией учетных записей пользователей см. в руководстве разработчика API каталога: учетные записи пользователей .
Сценарии использования аккаунтов Google
В следующем разделе описано несколько типичных сценариев предоставления идентификационных данных учетных записей Google.
Сценарий 1: Клиент несет ответственность за жизненный цикл аккаунта
В этом сценарии ваш клиент создает и поддерживает учетные записи Google для своих пользователей.
Вы получаете информацию об учетной записи пользователя из каталога LDAP организации и сопоставляете ее с данными учетной записи Google, которые вы получаете от Google, используя API каталога Google.
Организация несёт полную ответственность за жизненный цикл учётной записи. Например, при создании новой учётной записи Google организация добавляет пользователя в свой каталог LDAP. При следующей синхронизации базы данных с каталогом LDAP информация об этом новом пользователе будет добавлена в базу данных.
В этом сценарии:
- У вас есть доступ только для чтения к аккаунтам Google.
- Ваша база данных получает имена учетных записей Google, но не имена пользователей и пароли LDAP.
- Вы используете API Google Directory для получения базовой информации об учётных записях пользователей вашего клиента. (Вам доступна неизменяемая информация, возвращаемая запросом
Users.get). Вы используете эту информацию для проверки существования учётных записей Google пользователей, чтобы они могли аутентифицироваться на своих устройствах. - Ваш клиент использует инструмент GCDS для односторонней синхронизации, чтобы заполнить учётные записи Google пользователей. (Организация, вероятно, также использует GCDS для собственной текущей синхронизации после завершения предоставления удостоверений.) При желании организация может также использовать инструмент GSPS для синхронизации не только имён пользователей, но и паролей.
Сценарий 2: EMM отвечает за жизненный цикл аккаунта
В этом сценарии вы управляете процессом создания учетных записей Google от имени своего клиента и несете ответственность за жизненный цикл учетных записей пользователей.
Например, при изменении информации о пользователе в каталоге LDAP организации вы несёте ответственность за обновление учётной записи Google этого пользователя. GCDS в этом сценарии не используется.
В этом сценарии:
- У вас есть доступ на чтение и запись к аккаунтам Google.
- Ваша база данных получает имена учетных записей Google и имена пользователей LDAP (и, при необходимости, хэши паролей).
- Вы используете API Google Directory от имени своего клиента для чтения и записи информации об учётных записях пользователей организации. (Вам доступна неизменяемая информация, возвращаемая запросом
Users.get). Вы используете эту информацию для проверки существования учётных записей Google пользователей, чтобы они могли аутентифицироваться на своих устройствах. - Инструмент GCDS не используется.
Сценарии аутентификации SSO на основе SAML
При развертывании учётных записей Google вы или ваш клиент можете использовать язык разметки утверждений безопасности (SAML) с поставщиком удостоверений (IdP) для аутентификации учётной записи Google, связанной с каждым пользователем. Имена учётных записей Google используются для подтверждения существования учётных записей Google, что необходимо для аутентификации пользователей при входе в систему на своих устройствах. Например, SAML можно использовать в сценарии 2. Подробнее о настройке см. в статье Настройка единого входа (SSO) для учётных записей G Suite .