Kimlik sağlama (veya hesap sağlama), hesap oluşturma ve kullanıcı verilerini barındıran üç sistem arasında bağlantı kurma, bazı durumlarda ise kullanıcılar ile cihazları arasında bağlantı kurma işlemidir.
Android kurumsal ortamında, kullanıcı hesabı bilgilerini üç farklı sistem tutar:
- Kuruluşun kullanıcı dizini, kullanıcılarla ilgili bilgilerin kesin kaynağıdır.
- Siz (EMM çözümü sağlayıcı) kuruluşun kullanıcılarının en azından minimum bir dizinini tutmalısınız.
- Google, Google Play aracılığıyla uygulama yönetimi sağlamak için Managed Google Play hesapları ve Google Hesapları hakkında bazı bilgileri saklar.
Users kaynağı, bir kuruluşla ilişkili hesabı temsil eder. Hesap, cihaza özel olabilir veya birden fazla cihazı olan ve hesabı tüm cihazlarında kullanan bir kişiyle ilişkilendirilebilir. Hesap, müşterinizin işletmesini nasıl ayarladığınıza bağlı olarak yalnızca Managed Google Play'e veya diğer Google hizmetlerine erişim sağlayabilir:
Yönetilen Google Hesapları, Google tarafından yönetilen mevcut hesaplardır. Bu hesaplar, müşterinin Google'ı kimlik sağlayıcı olarak kullanmasını veya kuruluşunun kullanıcı dizinini Google'a bağlamasını gerektirir. Yönetilen Google Hesapları kullanan işletmelerde, cihaz temel hazırlığı sırasında kullanıcının kimliğini doğrulama sorumluluğu Google'a aittir.
Managed Google Play Accounts, işletmelerin kurumsal mobilite yönetimi (EMM) çözüm sağlayıcıları aracılığıyla sınırlı kullanıcı hesaplarını otomatik olarak oluşturmalarını sağlar. Bu hesaplar yalnızca Managed Google Play'e erişim sağlar. EMM, gerektiğinde kullanıcının kimliğini doğrulamaktan tamamen sorumludur. Managed Google Play Accounts gruplarında kullanılabilen tek hesap türü budur.
Tablo 1: Users API alanları ve yöntemleri
| Managed Google Play Accounts | yönetilen Google Hesapları | |
|---|---|---|
| Alan | ||
| id | ||
| tür | ||
| accountIdentifier | Oluşturduğunuz ve Google Play'den döndürülen kimlikle (userId) eşlediğiniz benzersiz bir tanımlayıcı. Kimliği tanımlayabilecek bilgiler (PII) kullanmayın. | Ayarlanmadı. |
| accountType | deviceAccount, userAccount | userAccount |
| görünen ad | Kullanıcı arayüzü öğelerinde (ör. Google Play) gösterdiğiniz ad. Kimliği tanımlayabilecek bilgiler kullanmayın. | Ayarlanmadı. |
| managementType | emmManaged | googleManaged, emmManaged |
| primaryEmail | Ayarlanmadı. | Bu alan, Google tarafından yönetilen alan hesaplarından sisteminizdeki kullanıcı hesaplarına senkronizasyonu yönettiğiniz birincil anahtardır. |
| Yöntemler | ||
| delete | ||
| generateAuthenticationToken | ||
| generateToken | ||
| get | ||
| getAvailableProductSet | ||
| insert | ||
| list | ||
| revokeToken | ||
| setAvailableProductSet | ||
| update | ||
Cihaz kaydıyla ilgili iyileştirmelerimiz kapsamında, kurumsal kimliği olan bir çalışanın kullandığı tüm Android Enterprise cihazlarda yönetilen Google Hesapları'na geçiş yapıyoruz.
Yeni kayıtlarda artık yönetilen Google Play hesapları yerine yönetilen Google Hesapları'nı kullanmanızı öneririz. Mevcut kullanıcılar için Managed Google Play Accounts'u desteklemeye devam etsek de bu hesaplar yalnızca Managed Google Play Store'a erişim sağlar. Yönetilen Google Hesapları, kullanıcılara Google hizmetlerinin tümüne ve cihazlar arası özelliklere erişim imkanı sunar.
Kayda ilişkin iyileştirmeler
Yönetilen Google Hesapları, kullanıcının Google'daki kimliğini oluşturur. Bu, görev devri, bildirimler ve yakındaki paylaşım gibi cihazlar arası deneyimleri etkinleştirir. Bu özellikler, kullanıcıların genellikle birden fazla cihaz kullandığı kurumsal alanda giderek daha önemli hale geliyor.
Google'ı kimlik sağlayıcı olarak kullanmayan işletmelerin mevcut kimlik sağlayıcılarını Google'a bağlamaları artık önemle tavsiye edilir. Bu sayede, bağlama işlemi sırasında çalışanlar için yönetilen Google Hesapları oluşturulabilir. Kuruluşlar, bu işlem için EMM'leriyle kullandıkları kimlik sağlayıcıyı kullanmalıdır.
Aşağıdaki değişiklikleri uyguladık:
Cihaz kaydı sırasında son kullanıcının kimlik doğrulaması artık Google/Android tarafından gerçekleştiriliyor. EMM'nin cihaz politikası denetleyicisi (DPC), Android'in kullanıcıyı uygun noktada kimlik doğrulamasını gerektirir. Ardından Android, oturum açmış kullanıcının kimliğini DPC'ye döndürür.
EMM, kullanıcı kimlik doğrulaması isterken Android'e kayıt jetonu iletmelidir. Bu jeton, Android Enterprise API'ye yapılan bir API çağrısı tarafından döndürülür ve QR, NFC veya sıfır dokunmayla kayıt yükünde kodlanmış olabilir.
Android artık kimlik doğrulama işlemini gerçekleştirip kullanıcı kimliğini EMM'ye sağlasa da kullanıcı kimliğini doğru grup veya kuruluş yapısıyla eşlemek hâlâ EMM'nin sorumluluğundadır. Bu eşleme, cihaza uygun politikaların uygulanması için gereklidir. Bu nedenle, kuruluşlar, kuruluşlarının kullanıcı dizinini EMM'lerine bağlamaya devam etmelidir.
BT yöneticileri, Google tarafından sağlanan yeni son kullanıcı kimlik doğrulama özelliğini etkinleştirebilir veya devre dışı bırakabilir. Kullanıcılara cihazlar arası özellikler de dahil olmak üzere en iyi deneyimi sunmak için BT yöneticilerinin kuruluşlarının kullanıcı dizinini Google'a bağlamasını öneririz. Bu bağlantı olmadan kullanıcılar, Managed Google Play Accounts'a sahip olur ancak cihazlar arası deneyimlere erişemez.
Tüm EMM'lerin kayıt ve oturum açma jetonları oluştururken ek bilgi sağlaması yeni bir zorunluluktur. Özellikle, artık bir cihazın kullanıcı olmadan kullanılıp kullanılmadığını (ör. kiosk veya özel cihaz) belirtmeniz gerekir.
Avantajları
Yeni süreç aşağıdaki önemli iyileştirmeleri sunar:
Basitleştirilmiş kayıt: Standart yöntemlere kıyasla manuel adımların sayısını ve karmaşıklığı azaltır.
Google Hesabı desteği: Artık Google Hesaplarını tüm sağlama yöntemleriyle kullanabilirsiniz. Bu sayede Managed Google Play Accounts'a gerek kalmaz.
Gelişmiş kullanıcı deneyimi: Yönetilen Google Hesapları ile paylaşım ve kopyala-yapıştır gibi güçlü cihazlar arası özelliklerin yer aldığı daha zengin bir Android deneyimi elde edersiniz.
Kullanıcı hesaplarının uygulanması
Bu yeni kayıt akışıyla nasıl devam edeceğinizi öğrenmek için Kullanıcı hesaplarını uygulama başlıklı makaleyi inceleyin.
Yönetilen Google Hesaplarının yaşam döngüsü
Google Hesapları'nı kullanan kuruluşlarda, bir EMM'nin çözümündeki kullanıcı hesapları, başka bir Google hizmetiyle (ör. Google Workspace) ilişkili mevcut kullanıcı hesaplarını yansıtır. Bu hesaplar, Google'ın arka uç hizmetleri hesabın oluşturulması ve hesapla ilgili bilgiler için kaynak olduğundan googleManaged
(Tablo 1) olarak sınıflandırılır.
EMM olarak, sisteminizde tutulan kullanıcı hesaplarının Google Cloud Directory Sync (GCDS) ve Google Admin SDK Directory API gibi araçları kullanarak Google alanı hesabı kaynaklarıyla oluşturulmasını ve sürekli senkronize edilmesini kolaylaştırmak için konsolunuzda mekanizmalar sağlayabilirsiniz. Çeşitli yaklaşımlara genel bir bakış için. Google tarafından yönetilen alan kimliği modeli, kullanıcı hesabının bir iş profili bağlamında kullanıcının cihazlarından herhangi birinde sağlanabilmesi için çözümünüz bağlamında (EMM konsolu, EMM sunucusu, belki bir veri deposunda) mevcut olmasını gerektirir.
Kimlik temel hazırlığı sırasında, kuruluşun Google tarafından yönetilen alanına kullanıcı hesapları eklenir. Bazı durumlarda, kullanıcıların mevcut online kimlikleri (ör. Microsoft Exchange hesapları) Google Hesaplarıyla senkronize edilir.
Müşteri hesaplarını senkronize etme
Google Hesapları dağıtımında kuruluş, G Suite alanındaki verileri LDAP dizinindeki verilerle senkronize etmek için GCDS aracını kullanabilir. Alternatif olarak, kuruluş size erişim izni verirse bu işlemi kuruluş adına yapmak için GCDS'yi kullanabilirsiniz.
GCDS aracı, Google Directory API'yi çağırır ve kullanıcı adlarını senkronize eder ancak şifreleri senkronize etmez.
Kuruluş Microsoft Active Directory kullanıyorsa ve kullanıcıların G Suite şifrelerini Active Directory şifreleriyle senkronize etmek istiyorsa GCDS ile G Suite Password Sync (GSPS) aracını kullanabilir.
Yöneticiler için GCDS talimatlarını G Suite alanınızı senkronizasyona hazırlama başlıklı makalede bulabilirsiniz.
Google Directory API
Google Hesapları dağıtımında, Google Directory API'yi kullanarak etkin dizinleri, şifreleri veya her ikisini de senkronize edebilirsiniz:
Yalnızca dizin senkronizasyonu için Directory API'yi kullanma Kuruluşun yönetilen Google alanına salt okuma erişiminiz varsa Google'dan kullanıcı adları (ancak şifreler değil) gibi Google Hesabı bilgilerini almak için Google Directory API'yi kullanabilirsiniz. Kullanıcıların Google Hesaplarına veri yazamadığınız için kuruluş, hesap yaşam döngülerinden tamamen sorumludur.
Senaryo 1 ve SAML tabanlı TOA kimlik doğrulama senaryoları bu durumu daha ayrıntılı bir şekilde açıklar.
Directory API'yi bu şekilde kullanma hakkında bilgi edinmek için Directory API dokümanlarındaki Tüm hesap kullanıcılarını alma başlıklı makaleyi inceleyin.
Dizin ve isteğe bağlı şifre senkronizasyonu için Directory API'yi kullanma. Kuruluşun yönetilen Google alanına okuma/yazma erişiminiz varsa kullanıcı adlarını, şifreleri ve diğer Google Hesabı bilgilerini almak için Google Directory API'yi kullanabilirsiniz. Bu bilgileri güncelleyip kendi veritabanınızla senkronize edebilirsiniz. Müşterinize sunduğunuz çözüme bağlı olarak hesap yaşam döngülerinden tamamen veya kısmen sorumlu olabilirsiniz.
2. senaryo bu durumu daha ayrıntılı bir şekilde açıklar.
Kullanıcı hesabı bilgilerini yönetmek için Directory API'yi kullanma hakkında daha fazla bilgi edinmek için Directory API: Kullanıcı Hesapları geliştirici kılavuzuna bakın.
Google Hesapları senaryoları
Aşağıdaki bölümde, Google Hesapları ile ilgili kimlik sağlama işlemlerinin birkaç tipik senaryosu açıklanmaktadır.
1. senaryo: Hesap yaşam döngülerinden müşteri sorumludur
Bu senaryoda müşteriniz, kullanıcıları için Google Hesapları oluşturur ve bu hesapları yönetir.
Kuruluşun LDAP dizininden kullanıcı hesabı bilgilerini alırsınız ve Google Directory API'yi kullanarak Google'dan aldığınız Google Hesabı verileriyle ilişkilendirirsiniz.
Hesap yaşam döngülerinden tamamen kuruluş sorumludur. Örneğin, yeni bir Google Hesabı oluşturulduğunda kuruluş, kullanıcıyı LDAP dizinine ekler. Veritabanınızı LDAP diziniyle bir sonraki senkronizasyonunuzda veritabanınız bu yeni kullanıcıyla ilgili bilgileri alır.
Bu senaryoda:
- Google Hesaplarına salt okuma erişiminiz var.
- Veritabanınız Google Hesabı adlarını alır ancak LDAP kullanıcı adlarını veya şifrelerini almaz.
- Müşterinizin kullanıcılarıyla ilgili temel hesap bilgilerini almak için Google Directory API'yi kullanıyorsunuz. (Size sunulan bilgiler, bir
Users.getisteğiyle döndürülen yazılamayan bilgilerdir). Bu bilgileri, kullanıcıların Google Hesaplarının mevcut olduğunu doğrulamak için kullanırsınız. Böylece kullanıcılar cihazlarının kimliğini doğrulayabilir. - Müşteriniz, kullanıcıların Google Hesaplarını doldurmak için GCDS aracını kullanarak tek yönlü senkronizasyon gerçekleştirir. (Kuruluş, kimlik sağlama tamamlandıktan sonra kendi devam eden senkronizasyonu için de GCDS'yi kullanıyor olabilir.) Kuruluş, isteğe bağlı olarak yalnızca kullanıcı adlarını değil, şifreleri de senkronize etmek için GSPS aracını da kullanabilir.
2. senaryo: EMM, hesap yaşam döngülerinden sorumludur
Bu senaryoda, müşteriniz adına Google Hesabı oluşturma sürecini yönetirsiniz ve kullanıcıların hesap yaşam döngülerinden siz sorumlusunuzdur.
Örneğin, kuruluşun LDAP dizinindeki kullanıcı bilgileri değiştiğinde kullanıcının Google Hesabı'nı güncellemekten siz sorumlusunuz. Bu senaryoda GCDS kullanılmaz.
Bu senaryoda:
- Google Hesapları'na okuma/yazma erişiminiz olmalıdır.
- Veritabanınız Google Hesabı adlarını ve LDAP kullanıcı adlarını (isteğe bağlı olarak şifre karmaları) alır.
- Müşteriniz adına Google Directory API'yi kullanarak kuruluş kullanıcılarının hesap bilgilerini okur ve yazar. (Size sunulan bilgiler, bir
Users.getisteğiyle döndürülen yazılamayan bilgilerdir). Bu bilgileri, kullanıcıların Google Hesaplarının mevcut olduğunu doğrulamak için kullanırsınız. Böylece kullanıcılar cihazlarının kimliğini doğrulayabilir. - GCDS aracı kullanılmıyor.
SAML tabanlı TOA kimlik doğrulama senaryoları
Google Hesapları dağıtımında, siz veya müşteriniz her kullanıcıyla ilişkili Google Hesabı'nın kimliğini doğrulamak için bir kimlik sağlayıcı (IdP) ile birlikte Güvenlik Onayı Biçimlendirme Dili (SAML) kullanabilirsiniz. Kullanıcıların cihazlarında oturum açtıklarında kullanıcı kimlik doğrulaması için gerekli olan, kullanıcıların Google Hesaplarının mevcut olduğunu doğrulamak amacıyla Google Hesabı adlarını kullanırsınız. Örneğin, SAML 2. Senaryo'da kullanılabilir. Bu ayarın nasıl yapılacağı hakkında ayrıntılı bilgi için G Suite hesapları için Tek Oturum Açma (TOA) ayarlarını yapma başlıklı makaleyi inceleyin.