Предоставление удостоверений (или предоставление учетных записей ) — это процесс настройки учетных записей и установления соединений между тремя системами, а в некоторых случаях — настройки соединений между пользователями и их устройствами.
В корпоративной среде 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). | Не установлено. |
Тип аккаунта | Аккаунт устройства, Аккаунт пользователя | учетная запись пользователя |
отображаемое имя | Имя, которое вы отображаете в элементах пользовательского интерфейса, например в Google Play. Не используйте личную информацию. | Не установлено. |
тип управления | emmУправляемый | GoogleManaged, emmManaged |
основной адрес электронной почты | Не установлено. | Это поле является основным ключом, с помощью которого вы управляете синхронизацией учетных записей домена, управляемых Google, с учетными записями пользователей в вашей системе. |
Методы | ||
удалить | ||
генерировать токен аутентификации | ||
генерировать токен | ||
получать | ||
получить доступныйпродуктсет | ||
вставлять | ||
список | ||
отзывтокен | ||
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 и ЦОД). Эти компоненты взаимодействуют во время выполнения для создания учетной записи пользователя и подготовки рабочего профиля на целевом устройстве . Ваша консоль или сервер EMM должны:
Предоставьте механизм создания уникальных идентификаторов анонимных учетных записей (поле
accountIdentifier
) для использования при вызовеUsers.insert
. Например, вы можете использовать какое-то внутреннее значение для пользователя («sanjeev237389») или загадочный номер тега актива («asset#44448»). Избегайте использования личной информации (PII) в качестве идентификатора учетной записи.Сохраните сопоставление между
userId
(возвращенным из вызоваinsert
) и выбранным вамиaccountIdentifier
.
Требования к вашему ЦОД см. в разделе Создание контроллера политики устройств .
Создайте управляемую учетную запись пользователя Google Play.
- Пользователь входит в ваш ЦОД, используя (обычно) корпоративные учетные данные.
- ЦОД запрашивает сведения о пользователе у сервера или консоли EMM. Предполагая, что пользователь неизвестен вашей системе:
- Отправьте запрос на новую управляемую учетную запись Google Play, вызвав
Users.insert
со значениями newaccountIdentifier
,displayName
иaccountType
.- Ваша система должна создать
accountIdentifier
. Идентификатор учетной записи должен быть уникальным значением в вашей системе. Не используйте PII в качестве идентификатора учетной записи. -
displayName
отображается в переключателе учетных записей Google Play Store и должно иметь некоторое значение для пользователя (но не PII о пользователе). Например, имя может включать название организации или общее имя, связанное с EMM. - Установите для
accountType
значениеuserAccount
илиdeviceAccount
.userAccount
можно использовать на нескольких устройствах, аdeviceAccount
предназначен только для одного устройства. УказанныйaccountType
может бытьdeviceType
илиuserType
. - Установите для
managementType
значениеemmManaged
.
- Ваша система должна создать
- Google Play обрабатывает запрос, создает учетную запись и возвращает
userId
. - Сохраните сопоставление между
accountIdentifier
иuserId
в своем хранилище данных. - Вызовите
Users.generateAuthenticationToken
указавuserId
иenterpriseId
. Google Play возвращает токен аутентификации, который можно использовать один раз и который необходимо использовать в течение нескольких минут. - Безопасно пересылайте токен аутентификации в свой ЦОД.
- Отправьте запрос на новую управляемую учетную запись Google Play, вызвав
- ЦОД подготавливает рабочий профиль и добавляет учетную запись в рабочий профиль или устройство.
- Пользователь может получить доступ к управляемому Google Play в рабочем профиле или на устройстве.
Учетные записи администратора
Когда администратор создает предприятие с управляемыми учетными записями Google Play , используемая им учетная запись Google не может быть учетной записью G Suite. Используемая ими учетная запись становится владельцем предприятия, и владелец может добавлять других владельцев и администраторов в управляемой консоли Google Play.
И Enterprises.get
, и Enterprises.completeSignup
возвращают список адресов электронной почты администраторов, связанных с предприятием (только предприятия с управляемыми учетными записями Google Play).
Управляйте жизненным циклом аккаунта
При развертывании управляемых учетных записей Google Play вы несете ответственность за жизненные циклы учетных записей пользователей и устройств, что означает, что вы создаете, обновляете и удаляете эти учетные записи.
Вы создаете учетные записи во время подготовки устройств — процесса, в котором участвуют ваше приложение DPC и консоль EMM. Инструкции см. в разделе «Метод управляемых учетных записей Google Play» .
Чтобы изменить информацию учетной записи, вызовите Users.update .
Чтобы удалить учетную запись, вызовите Users.delete .
Администраторы не могут удалять отдельные учетные записи, но могут удалить предприятие с управляемыми учетными записями Google Play. При этом учетные записи устройств и пользователей, связанные с предприятием, в конечном итоге удаляются, как описано в разделе «Отмена регистрации, повторная регистрация, удаление» .
Срок действия учетной записи истек
Иногда срок действия учетных записей или их токенов истекает, что может произойти по ряду причин:
- Срок действия токена аутентификации , полученного для добавления учетной записи на устройство, истек.
- Аккаунт или предприятие удалено .
- Для учетных записей устройств учетная запись была добавлена на новое устройство и поэтому отключена на старом устройстве.
- Запускаются автоматические проверки на злоупотребления.
В большинстве случаев (если только EMM не намеренно переносит учетную запись устройства на новое устройство) рекомендуется использовать Play EMM API для запроса нового токена с сервера EMM, отмечать состояние учетной записи и предприятия, а также все возвращенные данные. ошибки, а затем предпримите соответствующие действия на устройстве. Например, обновите токен или, если ошибку невозможно устранить, сбросьте или отмените регистрацию устройства.
Службы Google Play версии 9.0.00 уведомляют ваш ЦОД об истечении срока действия учетной записи с помощью широковещательного действия:
Когда управляемая учетная запись Google Play становится недействительной на устройстве, ЦОД получает широковещательное сообщение со следующим действием:
com.google.android.gms.auth.ACCOUNT_REAUTH_REQUIRED
Широковещательное намерение содержит дополнительный объект
Parcelable
с именемaccount
, который является объектомAccount
недействительной учетной записи.Центр обработки данных сверяет
Account#name
с сервером EMM, чтобы идентифицировать недействительную учетную запись.ЦОД либо запрашивает новые учетные данные, либо новую учетную запись, следуя тому же самому процессу, который использовался для первоначальной подготовки устройства .
Аккаунты Google
В организациях, использующих учетные записи Google, учетные записи пользователей в решении EMM отражают существующие учетные записи пользователей, связанные с другой службой Google (например, G Suite). Эти учетные записи 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 организация может использовать инструмент GCDS для синхронизации данных в своем домене G Suite с данными в своем каталоге LDAP. Альтернативно вы можете использовать GCDS, чтобы сделать это от имени организации, если организация предоставит вам доступ.
Инструмент GCDS вызывает API каталога Google и синхронизирует имена пользователей, но не пароли.
Если организация использует 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. Поскольку вы не можете записывать какие-либо данные в аккаунты Google пользователей, вся ответственность за жизненный цикл аккаунтов лежит на организации.
Сценарий 1 и сценарии аутентификации единого входа на основе 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 для получения основной информации об учетной записи пользователей вашего клиента. (Информация, доступная вам, — это закрытая для записи информация , возвращаемая запросом
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 пользователей, что необходимо для аутентификации пользователей при входе в систему на своих устройствах. Например, в сценарии 2 можно использовать SAML. Подробную информацию о том, как это настроить, см. в разделе Настройка единого входа (SSO) для учетных записей G Suite .
Активируйте учетные записи на устройствах
Чтобы приложения могли распространяться на пользовательское устройство через управляемый Google Play, пользователь должен войти на устройство во время его подготовки :
- При подготовке устройств с управляемыми учетными записями Google Play ваш ЦОД предлагает пользователю войти в систему, используя учетные данные, принятые вашей консолью EMM (обычно учетные данные корпоративной электронной почты).
- При развертывании учетных записей Google ваш DPC помогает пользователю ввести учетные данные для входа в учетную запись Google. Обычно эти учетные данные совпадают с теми, с которыми пользователи входят в свой корпоративный домен при синхронизации с GCDS или GSPS или когда организация использует IdP для аутентификации. Это активирует учетную запись Google пользователя, генерирует уникальный идентификатор устройства и связывает личность учетной записи Google и идентификатор устройства его устройства.