Предоставление учетных записей пользователей

Создание учетных записей (или идентификационных данных ) — это процесс настройки учетных записей и установления связей между тремя системами, а в некоторых случаях и установления связей между пользователями и их устройствами.

В корпоративной среде Android информация об учетных записях может храниться в трех разных системах:

  • Справочник пользователей организации является основным источником информации о пользователях.
  • Вы (поставщик решения EMM) должны поддерживать как минимум минимальный каталог пользователей организации.
  • Google хранит некоторую информацию об управляемых учетных записях Google Play и учетных записях Google для обеспечения управления приложениями через Google Play.

Ресурс Users представляет собой учетную запись, связанную с предприятием. Учетная запись может быть привязана к конкретному устройству или к отдельному пользователю, который использует эту учетную запись на нескольких устройствах (мобильный телефон, планшет и т. д.). В зависимости от настроек предприятия клиента , учетная запись может предоставлять доступ только к управляемому Google Play или к другим сервисам Google.

  • Управляемые учетные записи Google Play предоставляют предприятиям прозрачный способ автоматического создания учетных записей пользователей или устройств через поставщика решений для управления корпоративной мобильностью (EMM). Эти учетные записи предоставляют доступ только к управляемому Google Play.

  • Учетные записи Google — это существующие учетные записи, управляемые Google, и для их синхронизации с источниками учетных записей Google требуется синхронизация.

Таблица 1: Поля и методы API пользователей

Управление учетными записями Google Play Управляемые аккаунты Google
Поле
идентификатор
добрый
идентификатор учетной записи Уникальный идентификатор, который вы создаете и сопоставляете с идентификатором ( userId ), возвращаемым Google Play. Не используйте персональные данные (PII). Не задано.
тип учетной записи deviceAccount, userAccount учетная запись пользователя
отображаемое имя Имя, которое вы отображаете в элементах пользовательского интерфейса, например, в Google Play. Не используйте личную информацию, позволяющую идентифицировать пользователя. Не задано.
тип управления emmManaged googleManaged, emmManaged
основной адрес электронной почты Не задано. Это поле является первичным ключом, с помощью которого вы управляете синхронизацией между учетными записями домена, управляемыми Google, и учетными записями пользователей в вашей системе.
Методы
удалить
generateAuthenticationToken
generateToken
получать
getAvailableProductSet
вставлять
список
revokeToken
setAvailableProductSet
обновлять

Управление учетными записями Google Play

Существует два типа управляемых аккаунтов Google Play:

Учетная запись пользователя
Предоставляет одному пользователю доступ к управляемому Google Play со всех его устройств. Необходимо создать учетные записи для пользователей — у них нет учетных данных для самостоятельного добавления управляемых учетных записей Google Play.
Для создания учетной записи пользователя вызовите метод Users.insert . Установите тип учетной записи на userType и задайте accountIdentifier , который однозначно идентифицирует пользователя в рамках предприятия.
Рекомендация : не используйте одну и ту же учетную запись более чем на 10 устройствах.
Учетная запись устройства
Предоставляет доступ к управляемому Google Play с одного устройства. Если для учетной записи устройства был выдан токен аутентификации, новый запрос на получение токена аутентификации для этой учетной записи устройства деактивирует предыдущий токен. Каждое устройство должно иметь свои отдельные лицензии для приложений.
Для создания учетной записи устройства вызовите метод Users.insert и установите тип учетной записи в deviceType .

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

Требования к консолям и серверам EMM

Управляемые учетные записи Google Play создаются по запросу, программно, с использованием API Google Play EMM и API платформы Android во всех компонентах вашего решения EMM (консоль EMM, сервер EMM и DPC). Эти компоненты взаимодействуют во время выполнения для создания учетной записи пользователя и подготовки рабочего профиля на целевом устройстве .

Ваша консоль или сервер EMM должны:

  • Предусмотрите механизм для создания уникальных анонимных идентификаторов учетных записей (поле accountIdentifier ) ​​для использования в вызове Users.insert . Например, вы можете использовать какое-либо внутреннее значение для пользователя ("sanjeev237389") или загадочный номер инвентарного тега ("asset#44448"). Избегайте использования персональных данных (PII) в качестве идентификатора учетной записи.

  • Сохраните сопоставление между userId (возвращаемым из вызова функции insert ) и выбранным вами accountIdentifier .

Требования к вашему DPC см. в разделе «Создание контроллера политик устройств» .

Создайте управляемый пользовательский аккаунт Google Play.

  1. Пользователь входит в вашу систему DPC, используя (как правило) корпоративные учетные данные.
  2. DPC запрашивает подробную информацию о пользователе у сервера или консоли EMM. Предположим, что пользователь неизвестен вашей системе:
    1. Отправьте запрос на создание нового управляемого аккаунта Google Play, вызвав метод Users.insert со значениями для новых accountIdentifier , displayName и accountType .
      • Ваша система должна создать accountIdentifier . Идентификатор учетной записи должен быть уникальным значением во всей системе. Не используйте персональные данные (PII) в качестве идентификатора учетной записи.
      • displayName отображается в меню переключения учетных записей в Google Play Store и должно иметь какое-либо значение для пользователя (но не содержать персональных данных пользователя). Например, имя может включать название организации или общее название, связанное с EMM.
      • Установите accountType в значение userAccount или deviceAccount . userAccount может использоваться на нескольких устройствах, тогда как deviceAccount привязана к одному устройству. В качестве accountType может быть указан deviceType или userType .
      • Установите параметр managementType в emmManaged .
    2. Google Play обрабатывает запрос, создает учетную запись и возвращает userId .
    3. Сохраните сопоставление между accountIdentifier и userId в вашем хранилище данных.
    4. Вызовите метод Users.generateAuthenticationToken , указав userId и enterpriseId . Google Play вернет токен аутентификации, который можно использовать один раз и который необходимо использовать в течение нескольких минут.
    5. Надежно перешлите токен аутентификации в ваш DPC.
  3. DPC создает рабочий профиль и добавляет учетную запись к рабочему профилю или устройству.
  4. Пользователь может получить доступ к управляемому Google Play в рамках рабочего профиля или на устройстве.

Административные учетные записи

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

Методы Enterprises.get и Enterprises.completeSignup возвращают список адресов электронной почты администраторов, связанных с предприятием (только для предприятий с управляемыми учетными записями Google Play).

Управление жизненным циклом учетных записей

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

Учетные записи создаются во время настройки устройства, в процессе которой задействованы ваше приложение DPC и консоль EMM. Инструкции см. в разделе «Управляемые учетные записи Google Play» .

Для изменения информации об учетной записи вызовите команду Users.update .

Для удаления учетной записи вызовите команду Users.delete .

Администраторы не могут удалять отдельные учетные записи, но они могут удалить корпоративную учетную запись с управляемыми учетными записями Google Play. При этом в конечном итоге удаляются устройства и учетные записи пользователей, связанные с корпоративной учетной записью, как описано в разделе «Отмена регистрации, повторная регистрация, удаление» .

Срок действия учетной записи истекает

Иногда срок действия учетных записей или их токенов истекает, что может произойти по ряду причин:

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

Для корректного обновления токена необходимо:

  1. Вызовите метод users.generateAuthenticationToken , чтобы запросить новый токен аутентификации для учетной записи.
  2. Если вызов пройден успешно, удалите существующую учетную запись и добавьте новую, используя библиотеку поддержки DPC.
  3. Если вызов не удался, удалите учетную запись с устройства и создайте нового пользователя, используя users.insert , сгенерируйте токен аутентификации и добавьте учетную запись на устройство.

Сервисы Google Play версии 9.0.00 уведомляют ваш DPC о том, что срок действия учетной записи истек, используя действие широковещательной рассылки:

  1. Когда управляемая учетная запись Google Play на устройстве аннулируется, DPC получает широковещательное сообщение со следующим действием:

    com.google.android.gms.auth.ACCOUNT_REAUTH_REQUIRED

    Интент широковещательной рассылки содержит дополнительный объект Parcelable с именем account , который представляет собой объект Account недействительной учетной записи.

  2. DPC проверяет Account#name на сервере EMM, чтобы идентифицировать недействительную учетную запись.

  3. DPC либо запрашивает новые учетные данные, либо новую учетную запись, следуя той же процедуре, которая использовалась для первоначальной настройки устройства .

Аккаунты 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, как описано в разделе «Активация учетных записей на устройствах» . Эта активация позволяет устройству получить доступ к управляемому Google Play.

Синхронизация учетных записей клиентов

В рамках развертывания Google Accounts организация может использовать инструмент GCDS для синхронизации данных в своем домене Google Workspace с данными в своем каталоге LDAP. В качестве альтернативы, вы можете использовать GCDS для выполнения этой задачи от имени организации, если организация предоставит вам доступ.

Инструмент GCDS обращается к API каталога Google и синхронизирует имена пользователей, но не пароли.

Если организация использует Microsoft Active Directory и хочет синхронизировать пароли пользователей Google Workspace с их паролями Active Directory, см. раздел «Подготовка к использованию синхронизации паролей» .

Инструкции по использованию GCDS для администраторов см. в разделе «Авторизация учетной записи Google» .

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: Клиент отвечает за жизненный цикл учетной записи.

Использование API каталога (с доступом только для чтения) и GCDS

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

Вы получаете информацию об учетных записях пользователей из LDAP-каталога организации и сопоставляете ее с данными учетных записей Google, которые получаете от Google через Google Directory API .

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

В этом сценарии:

  • У вас есть доступ только для чтения к учетным записям Google.
  • Ваша база данных получает имена учетных записей Google, но не имена пользователей или пароли LDAP.
  • Вы используете API каталога Google для получения основной информации об учетных записях пользователей ваших клиентов. (Доступная вам информация — это не подлежащая записи информация, возвращаемая запросом Users.get ). Вы используете эту информацию для проверки существования учетных записей Google пользователей, чтобы они могли пройти аутентификацию на своих устройствах.
  • Ваш клиент использует инструмент GCDS для односторонней синхронизации, чтобы заполнить учетные записи Google пользователей. (Организация, вероятно, также использует GCDS для собственной текущей синхронизации после завершения предоставления идентификационных данных.) При желании организация может также использовать инструмент GSPS для синхронизации не только имен пользователей, но и паролей.

Сценарий 2: EMM отвечает за жизненные циклы учетных записей.

Использование API каталога с доступом на чтение и запись.

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

Например, при изменении информации о пользователе в LDAP-каталоге организации вы несете ответственность за обновление учетной записи Google этого пользователя. В этом сценарии GCDS не используется.

В этом сценарии:

  • У вас есть права на чтение и запись в учетные записи Google.
  • Ваша база данных получает имена учетных записей Google и имена пользователей LDAP (а также, при необходимости, хеши паролей).
  • Вы используете API каталога Google от имени вашего клиента для чтения и записи информации об учетных записях пользователей организации. (Доступная вам информация — это не подлежащая записи информация, возвращаемая запросом Users.get ). Вы используете эту информацию для проверки существования учетных записей Google пользователей, чтобы они могли пройти аутентификацию на своих устройствах.
  • Инструмент GCDS не используется.

Сценарии аутентификации SSO на основе SAML

В развертывании учетных записей Google вы или ваш клиент можете использовать язык разметки утверждений безопасности (SAML) с поставщиком идентификации (IdP) для аутентификации учетной записи Google, связанной с каждым пользователем. Вы используете имена учетных записей Google в качестве подтверждения существования учетных записей Google пользователей, что необходимо для аутентификации пользователей при входе в систему на своих устройствах. Например, SAML можно использовать в сценарии 2. Подробную информацию о настройке см. в разделе «Об SSO» .

Активируйте учетные записи на устройствах

Для распространения приложений на устройство пользователя через управляемый Google Play пользователь должен войти в систему устройства во время его инициализации :

  • В режиме управления учетными записями Google Play на устройствах ваш DPC направляет пользователя на вход с использованием учетных данных, принимаемых вашей консолью EMM, как правило, это корпоративные электронные почтовые аккаунты.
  • В развертывании учетных записей Google ваш DPC направляет пользователя на ввод учетных данных для входа в учетную запись Google. Обычно эти учетные данные совпадают с теми, которые пользователи используют для входа в корпоративный домен при синхронизации с GCDS или GSPS, или когда организация использует IdP для аутентификации. Это активирует учетную запись Google пользователя, генерирует уникальный идентификатор устройства и связывает идентификатор учетной записи Google пользователя с идентификатором устройства.