Provisioning tożsamości (lub provisioning kont) to proces konfigurowania kont i ustanawiania połączeń między 3 systemami, w których przechowywane są dane użytkowników, a w niektórych przypadkach także konfigurowania połączeń między użytkownikami a ich urządzeniami.
W środowisku Androida Enterprise informacje o kontach użytkowników są przechowywane w 3 różnych systemach:
- Katalog użytkowników organizacji jest ostatecznym źródłem informacji o użytkownikach.
- Ty (dostawca rozwiązania EMM) musisz prowadzić co najmniej minimalny katalog użytkowników organizacji.
- Google przechowuje niektóre informacje o kontach zarządzanego Sklepu Google Play i kontach Google, aby umożliwić zarządzanie aplikacjami za pomocą Google Play.
Zasób Users reprezentuje konto powiązane z przedsiębiorstwem. Konto może być przypisane do konkretnego urządzenia lub do osoby, która ma kilka urządzeń i korzysta z konta na wszystkich z nich. Konto może zapewniać dostęp tylko do zarządzanego Sklepu Google Play lub do innych usług Google, w zależności od tego, jak skonfigurujesz przedsiębiorstwo klienta:
Zarządzane konta Google to istniejące konta, którymi zarządza Google. Wymagają one, aby klient używał Google jako dostawcy tożsamości lub powiązał katalog użytkowników organizacji z Google. W przypadku firm korzystających z zarządzanych kont Google za uwierzytelnianie użytkownika podczas obsługi administracyjnej urządzenia odpowiada Google.
Konta zarządzanego Sklepu Google Play umożliwiają firmom automatyczne tworzenie ograniczonych kont użytkowników za pomocą dostawcy usług zarządzania urządzeniami mobilnymi (EMM). Te konta zapewniają dostęp tylko do zarządzanego Sklepu Google Play. Platforma EMM jest w pełni odpowiedzialna za uwierzytelnianie użytkownika w razie potrzeby. W przypadku grup kont zarządzanego Sklepu Google Play jest to jedyny dostępny typ konta.
Tabela 1. Pola i metody interfejsu Users API
| konta w zarządzanym Sklepie Google Play | zarządzane konta Google | |
|---|---|---|
| Pole | ||
| id | ||
| rodzaj | ||
| accountIdentifier | Unikalny identyfikator, który tworzysz i mapujesz na identyfikator (userId) zwrócony przez Google Play. Nie używaj informacji umożliwiających identyfikację osób. | Nie ustawiono. |
| accountType | deviceAccount, userAccount | userAccount |
| wyświetlanaNazwa | Nazwa wyświetlana w elementach interfejsu, np. w Google Play. Nie używaj informacji umożliwiających identyfikację osób. | Nie ustawiono. |
| managementType | emmManaged | googleManaged, emmManaged |
| primaryEmail | Nie ustawiono. | To pole jest kluczem podstawowym, za pomocą którego zarządzasz synchronizacją kont domen zarządzanych przez Google z kontami użytkowników w Twoim systemie. |
| Metody | ||
| usuń | ||
| generateAuthenticationToken | ||
| generateToken | ||
| get | ||
| getAvailableProductSet | ||
| Insert | ||
| lista | ||
| revokeToken | ||
| setAvailableProductSet | ||
| update | ||
W ramach ulepszania procesu rejestracji urządzeń przechodzimy na korzystanie z zarządzanych kont Google na wszystkich urządzeniach z Androidem Enterprise używanych przez pracownika z tożsamością służbową.
W przypadku nowych rejestracji zalecamy teraz używanie zarządzanych kont Google zamiast zarządzanych kont Google Play. Nadal obsługujemy konta zarządzanego Sklepu Google Play dla obecnych użytkowników, ale zapewniają one dostęp tylko do zarządzanego Sklepu Google Play. Zarządzane konta Google zapewniają użytkownikom dostęp do pełnego pakietu usług Google i funkcji na różnych urządzeniach.
Ulepszenia rejestracji
Zarządzane konta Google potwierdzają tożsamość użytkownika w Google. Umożliwia to korzystanie z funkcji na różnych urządzeniach, takich jak przekazywanie zadań, powiadomienia i udostępnianie w pobliżu. Te funkcje są coraz ważniejsze w przypadku firm, w których użytkownicy często korzystają z wielu urządzeń.
Firmy, które nie używają Google jako dostawcy tożsamości, powinny teraz połączyć swojego dotychczasowego dostawcę tożsamości z Google. Umożliwia to tworzenie zarządzanych kont Google dla pracowników podczas procesu łączenia. Przedsiębiorstwa powinny używać tego samego dostawcy tożsamości, co w przypadku platformy EMM.
Wprowadziliśmy te zmiany:
Uwierzytelnianie użytkownika podczas rejestracji urządzenia jest teraz obsługiwane przez Google/Androida. Kontroler zasad dotyczących urządzeń EMM wymaga, aby Android uwierzytelnił użytkownika w odpowiednim momencie, a następnie zwrócił do kontrolera tożsamość zalogowanego użytkownika.
Gdy system EMM zażąda uwierzytelnienia użytkownika, musi przekazać token rejestracji do Androida. Ten token jest zwracany przez wywołanie interfejsu Androida Enterprise API i może być zakodowany w ładunku rejestracji za pomocą kodu QR, NFC lub bezdotykowej.
Android obsługuje teraz uwierzytelnianie i przekazuje tożsamość użytkownika do usługi EMM, ale to usługa EMM nadal odpowiada za mapowanie tożsamości użytkownika na odpowiednią grupę lub strukturę organizacyjną. To mapowanie jest niezbędne do zastosowania odpowiednich zasad na urządzeniu. Dlatego przedsiębiorstwa muszą nadal łączyć katalog użytkowników organizacji z rozwiązaniem EMM.
Administratorzy IT mogą włączyć lub wyłączyć nową funkcję uwierzytelniania użytkowników dostarczaną przez Google. Aby zapewnić użytkownikom jak najlepsze wrażenia, w tym funkcje na różnych urządzeniach, zalecamy administratorom IT połączenie katalogu użytkowników organizacji z Google. Bez tego połączenia użytkownicy będą mieć zarządzane konta Google Play i nie będą mieć dostępu do funkcji na różnych urządzeniach.
Nowym wymaganiem dla wszystkich dostawców EMM jest podawanie dodatkowych informacji podczas tworzenia tokenów rejestracji i logowania. Musisz teraz określić, czy urządzenie jest bezużytkownikowe (np. kiosk lub urządzenie dedykowane).
Zalety
Nowy proces oferuje te kluczowe ulepszenia:
Uproszczona rejestracja: w porównaniu ze standardowymi metodami zmniejsza liczbę kroków wykonywanych ręcznie i złożoność procesu.
Obsługa kont Google: możesz teraz używać kont Google ze wszystkimi metodami udostępniania. Eliminuje to potrzebę korzystania z kont zarządzanego Sklepu Google Play.
Ulepszona wygoda użytkowników: zarządzane konta Google zapewniają bogatsze środowisko Androida, które obejmuje zaawansowane funkcje działające na różnych urządzeniach, takie jak udostępnianie i kopiowanie oraz wklejanie.
Wdrażanie kont użytkowników
Aby dowiedzieć się, jak postępować w przypadku tego nowego procesu rejestracji, przeczytaj artykuł Wdrażanie kont użytkowników.
Cykl życia zarządzanych kont Google
W przypadku organizacji korzystających z kont Google konta użytkowników w rozwiązaniu EMM odzwierciedlają istniejące konta użytkowników powiązane z inną usługą Google (np. Google Workspace). Te konta są googleManaged(tabela 1), ponieważ
usługi backendu Google są źródłem informacji o koncie i jego tworzenia.
Jako dostawca EMM możesz udostępniać w konsoli mechanizmy ułatwiające tworzenie i bieżącą synchronizację kont użytkowników w Twoim systemie z ich źródłami kont w domenie Google za pomocą narzędzi takich jak Google Cloud Directory Sync (GCDS) i interfejs Directory API z pakietu Google Admin SDK. Przegląd różnych podejść znajdziesz w tym artykule. Model tożsamości domeny zarządzanej przez Google wymaga, aby konto użytkownika istniało w kontekście Twojego rozwiązania (konsola EMM, serwer EMM, być może w magazynie danych), zanim będzie można je udostępnić na dowolnym urządzeniu użytkownika w kontekście profilu służbowego.
Podczas obsługi administracyjnej tożsamości domena zarządzana przez Google w organizacji jest wypełniana kontami użytkowników. W niektórych przypadkach istniejące tożsamości online użytkowników (np. konta Microsoft Exchange) są synchronizowane z ich kontami Google.
Synchronizowanie kont klientów
W przypadku wdrożenia kont Google organizacja może używać narzędzia GCDS do synchronizowania danych w domenie G Suite z danymi w katalogu LDAP. Możesz też użyć GCDS, aby zrobić to w imieniu organizacji, jeśli organizacja przyzna Ci dostęp.
Narzędzie GCDS wywołuje interfejs Google Directory API i synchronizuje nazwy użytkowników, ale nie hasła.
Jeśli organizacja używa Microsoft Active Directory i chce synchronizować hasła użytkowników w G Suite z hasłami w Active Directory, może użyć narzędzia G Suite Password Sync (GSPS) z GCDS.
Instrukcje dotyczące GCDS dla administratorów znajdziesz w artykule Przygotowywanie domeny G Suite do synchronizacji.
Google Directory API
W przypadku wdrożenia kont Google możesz użyć interfejsu Google Directory API do synchronizowania aktywnych katalogów, haseł lub obu tych elementów:
Korzystanie z interfejsu Directory API do synchronizacji tylko katalogu. Jeśli masz dostęp tylko do odczytu do zarządzanej domeny Google organizacji, możesz użyć interfejsu Google Directory API, aby uzyskać z Google informacje o kontach Google, takie jak nazwy użytkowników (ale nie hasła). Nie możesz zapisywać żadnych danych na kontach Google użytkowników, więc organizacja ponosi pełną odpowiedzialność za cykle życia kont.
Więcej informacji na ten temat znajdziesz w scenariuszu 1 i scenariuszach uwierzytelniania logowania jednokrotnego opartego na SAML.
Informacje o używaniu interfejsu Directory API w ten sposób znajdziesz w artykule Pobieranie wszystkich użytkowników konta w dokumentacji interfejsu Directory API.
Używanie interfejsu Directory API do synchronizowania katalogu i opcjonalnie haseł. Jeśli masz dostęp do zarządzanej domeny Google organizacji z uprawnieniami do odczytu i zapisu, możesz użyć interfejsu Google Directory API, aby uzyskać nazwy użytkowników, hasła i inne informacje o kontach Google. Możesz aktualizować te informacje i synchronizować je z własną bazą danych. W zależności od rozwiązania oferowanego klientowi możesz ponosić pełną lub częściową odpowiedzialność za cykle życia kont.
Scenariusz 2 dokładniej opisuje tę sytuację.
Więcej informacji o zarządzaniu informacjami o kontach użytkowników za pomocą interfejsu Directory API znajdziesz w przewodniku dla programistów Directory API: konta użytkowników.
Scenariusze dotyczące kont Google
W następnej sekcji opisujemy kilka typowych scenariuszy udostępniania tożsamości na kontach Google.
Scenariusz 1. Klient odpowiada za cykle życia kont
W tym scenariuszu klient tworzy konta Google dla swoich użytkowników i nimi zarządza.
Informacje o kontach użytkowników pobierasz z katalogu LDAP organizacji i korelujesz je z danymi kont Google, które otrzymujesz od Google za pomocą interfejsu Directory API.
Organizacja ponosi pełną odpowiedzialność za cykle życia kont. Na przykład po utworzeniu nowego konta Google organizacja dodaje użytkownika do katalogu LDAP. Przy następnej synchronizacji bazy danych z katalogiem LDAP baza danych otrzyma informacje o tym nowym użytkowniku.
W tym scenariuszu:
- Masz dostęp tylko do odczytu kont Google.
- Twoja baza danych uzyskuje nazwy kont Google, ale nie nazwy użytkowników LDAP ani hasła.
- Za pomocą interfejsu Google Directory API możesz uzyskiwać podstawowe informacje o kontach użytkowników klienta. (Dostępne dla Ciebie informacje to informacje, których nie można modyfikować, zwracane przez żądanie
Users.get). Używasz tych informacji, aby sprawdzić, czy konta Google użytkowników istnieją, dzięki czemu mogą oni uwierzytelniać się na swoich urządzeniach. - Klient używa narzędzia GCDS do synchronizacji w jednym kierunku, aby wypełnić konta Google użytkowników. (Organizacja prawdopodobnie używa też GCDS do własnej bieżącej synchronizacji po zakończeniu udostępniania tożsamości). Opcjonalnie organizacja może też używać narzędzia GSPS do synchronizowania nie tylko nazw użytkowników, ale też haseł.
Scenariusz 2. EMM odpowiada za cykle życia kont
W tym scenariuszu tworzysz konta Google w imieniu klienta i odpowiadasz za cykl życia kont użytkowników.
Jeśli na przykład informacje o użytkowniku zmienią się w katalogu LDAP organizacji, musisz zaktualizować konto Google tego użytkownika. W tym scenariuszu GCDS nie jest używany.
W tym scenariuszu:
- Masz uprawnienia do odczytu i zapisu na kontach Google.
- Baza danych uzyskuje nazwy kont Google i nazwy użytkowników LDAP (oraz opcjonalnie hasze haseł).
- W imieniu klienta używasz interfejsu Google Directory API do odczytywania i zapisywania informacji o kontach użytkowników organizacji. (Dostępne informacje to informacje, których nie można modyfikować, zwracane przez żądanie
Users.get). Używasz tych informacji, aby sprawdzić, czy konta Google użytkowników istnieją, dzięki czemu mogą oni uwierzytelniać się na swoich urządzeniach. - Narzędzie GCDS nie jest używane.
Scenariusze uwierzytelniania logowania jednokrotnego opartego na SAML
W przypadku wdrożenia kont Google Ty lub Twój klient możecie używać protokołu SAML (Security Assertion Markup Language) z dostawcą tożsamości do uwierzytelniania kont Google powiązanych z poszczególnymi użytkownikami. Nazwy kont Google służą do weryfikacji, czy konta Google użytkowników istnieją. Jest to potrzebne do uwierzytelniania użytkowników podczas logowania się na urządzenia. Na przykład w scenariuszu 2 można użyć SAML. Szczegółowe informacje o tym, jak to skonfigurować, znajdziesz w artykule Konfigurowanie logowania jednokrotnego na kontach G Suite.