Идентификационная регистрация (или регистрация учетных записей ) — это процесс создания учетных записей и установления связей между тремя системами, хранящими данные пользователей, а в некоторых случаях — установления связей между пользователями и их устройствами.
В корпоративной среде 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, используемых сотрудниками с корпоративной идентичностью.
Для новых пользователей мы теперь рекомендуем использовать управляемые учетные записи 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 API и может быть закодирован в 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 Accounts организация может использовать инструмент GCDS для синхронизации данных в своем домене Google Workspace с данными в своем каталоге LDAP. В качестве альтернативы, вы можете использовать GCDS для выполнения этой задачи от имени организации, если организация предоставит вам доступ.
Инструмент GCDS обращается к API каталога Google и синхронизирует имена пользователей, но не пароли.
Если организация использует Microsoft Active Directory и хочет синхронизировать пароли пользователей Google Workspace с их паролями Active Directory, см. раздел «Подготовка к использованию синхронизации паролей» .
Инструкции по использованию GCDS для администраторов см. в разделе «О синхронизации каталогов Google Cloud» .
API каталога Google
В среде Google Accounts вы можете использовать API Google Directory для синхронизации активных каталогов, паролей или того и другого:
Использование API каталога для синхронизации только каталога. Если у вас есть доступ только для чтения к управляемому домену Google организации, вы можете использовать API каталога Google для получения информации об учетных записях Google, такой как имена пользователей (но не пароли) от Google. Поскольку вы не можете записывать какие-либо данные в учетные записи Google пользователей, организация несет полную ответственность за жизненный цикл учетных записей.
Сценарий 1 и сценарии аутентификации SSO на основе SAML более полно описывают эту ситуацию.
Для получения информации об использовании API каталога таким образом см. раздел «Получение всех пользователей учетных записей» в документации по API каталога.
Использование API каталога для синхронизации каталога и, при необходимости, паролей. Если у вас есть права на чтение и запись в управляемый домен Google организации, вы можете использовать API каталога Google для получения имен пользователей, паролей и другой информации об учетных записях Google. Вы можете обновлять эту информацию и синхронизировать ее со своей собственной базой данных, и в зависимости от предлагаемого вами решения вы можете нести полную или частичную ответственность за жизненные циклы учетных записей.
Второй сценарий описывает эту ситуацию более подробно.
Для получения дополнительной информации об использовании Directory API для управления информацией об учетных записях пользователей см. руководство разработчика Directory API: User Accounts .
Сценарии использования учетных записей Google
В следующем разделе описаны несколько типичных сценариев предоставления идентификационных данных для учетных записей Google.
Сценарий 1: Клиент отвечает за жизненный цикл учетной записи.
В этом сценарии ваш клиент создает и поддерживает учетные записи Google для своих пользователей.
Вы получаете информацию об учетных записях пользователей из LDAP-каталога организации и сопоставляете ее с данными учетных записей Google, которые получаете от Google с помощью API каталога Google.
Организация несет полную ответственность за жизненные циклы учетных записей. Например, при создании новой учетной записи Google организация добавляет пользователя в свой LDAP-каталог. При следующей синхронизации базы данных с LDAP-каталогом ваша база данных получит информацию об этом новом пользователе.
В этом сценарии:
- У вас есть доступ только для чтения к учетным записям Google.
- Ваша база данных получает имена учетных записей Google, но не имена пользователей или пароли LDAP.
- Вы используете API каталога Google для получения основной информации об учетных записях пользователей ваших клиентов. (Доступная вам информация — это не подлежащая записи информация, возвращаемая запросом
Users.get). Вы используете эту информацию для проверки существования учетных записей Google пользователей, чтобы они могли пройти аутентификацию на своих устройствах. - Ваш клиент использует инструмент GCDS для односторонней синхронизации, чтобы заполнить учетные записи Google пользователей. (Организация, вероятно, также использует GCDS для собственной текущей синхронизации после завершения предоставления идентификационных данных.) При желании организация может также использовать инструмент GSPS для синхронизации не только имен пользователей, но и паролей.
Сценарий 2: EMM отвечает за жизненные циклы учетных записей.
В этом сценарии вы занимаетесь процессом создания учетных записей Google от имени вашего клиента и отвечаете за жизненный цикл учетных записей пользователей.
Например, при изменении информации о пользователе в LDAP-каталоге организации вы несете ответственность за обновление учетной записи Google этого пользователя. В этом сценарии GCDS не используется.
В этом сценарии:
- У вас есть права на чтение и запись в учетные записи Google.
- Ваша база данных получает имена учетных записей Google и имена пользователей LDAP (а также, при необходимости, хеши паролей).
- Вы используете API каталога Google от имени вашего клиента для чтения и записи информации об учетных записях пользователей организации. (Доступная вам информация — это не подлежащая записи информация, возвращаемая запросом
Users.get). Вы используете эту информацию для проверки существования учетных записей Google пользователей, чтобы они могли пройти аутентификацию на своих устройствах. - Инструмент GCDS не используется.
Сценарии аутентификации SSO на основе SAML
В развертывании учетных записей Google вы или ваш клиент можете использовать язык разметки утверждений безопасности (SAML) с поставщиком идентификации (IdP) для аутентификации учетной записи Google, связанной с каждым пользователем. Вы используете имена учетных записей Google в качестве подтверждения существования учетных записей Google пользователей, что необходимо для аутентификации пользователей при входе в систему на своих устройствах. Например, SAML можно использовать в сценарии 2. Подробную информацию о настройке см. в разделе «Об SSO» .