الهويات وحسابات المستخدمين

توفير الهوية (أو توفير الحساب) هو عملية إعداد الحسابات وإنشاء روابط بين الأنظمة الثلاثة التي تحتوي على بيانات المستخدمين، وفي بعض الحالات، إعداد روابط بين المستخدمين وأجهزتهم.

في بيئة Android Enterprise، تحتفظ ثلاثة أنظمة مختلفة بمعلومات حسابات المستخدمين:

• دليل المستخدمين في المؤسسة هو المصدر النهائي للمعلومات عن المستخدمين.
• عليك (مزوّد حلّ إدارة الخدمات الجوّالة للمؤسسات) الاحتفاظ بدليل أساسي على الأقل لمستخدمي المؤسسة.
• تحتفظ Google ببعض المعلومات عن حسابات Google Play للأعمال وحسابات Google لتوفير إدارة التطبيقات من خلال Google Play.

---

يمثّل مورد Users حسابًا مرتبطًا بمؤسسة. يمكن أن يكون الحساب خاصًا بجهاز معيّن، أو يمكن ربطه بمستخدم لديه أجهزة متعدّدة ويستخدم الحساب على جميعها. يمكن أن يوفّر الحساب إمكانية الوصول إلى Google Play للأعمال فقط، أو إلى خدمات Google الأخرى، وذلك حسب طريقة إعداد مؤسسة العميل:

• حسابات Google المُدارة هي حسابات حالية تديرها Google. تتطلّب هذه الحسابات من العميل إما استخدام Google كموفّر للهوية أو ربط دليل مستخدمي مؤسسته بـ Google. بالنسبة إلى المؤسسات التي تستخدم حسابات Google المُدارة، تكون Google مسؤولة عن مصادقة المستخدم أثناء إدارة الجهاز.

• توفّر حسابات Google Play للأعمال طريقة للمؤسسات لإنشاء حسابات مستخدمين محدودة تلقائيًا من خلال موفّر حلّ إدارة الخدمات الجوّالة للمؤسسات. توفّر هذه الحسابات إمكانية الوصول إلى Google Play للأعمال فقط. تكون إدارة الخدمات الجوّالة للمؤسسات مسؤولة بالكامل عن مصادقة المستخدم عند الحاجة. بالنسبة إلى مؤسسات حسابات Google Play للأعمال، هذا هو نوع الحساب الوحيد المتاح.

الجدول 1: حقول وطُرق واجهة برمجة التطبيقات Users

	حسابات Google Play للأعمال	حسابات Google المُدارة
الحقل
id
النوع
accountIdentifier	معرّف فريد تنشئه وتربطه بالمعرّف (userId) الذي يعرضه Google Play. لا تستخدِم معلومات تحديد الهوية الشخصية (PII).	لم يتم ضبطه.
accountType	deviceAccount وuserAccount	userAccount
displayName	الاسم الذي تعرضه في عناصر واجهة المستخدم، مثل Google Play. لا تستخدِم معلومات تكشف الهوية الشخصية.	لم يتم ضبطه.
managementType	emmManaged	googleManaged وemmManaged
primaryEmail	لم يتم ضبطه.	هذا الحقل هو المفتاح الأساسي الذي تستخدمه لإدارة المزامنة من حسابات النطاق المُدارة من Google إلى حسابات المستخدمين في نظامك.
الطُرق
حذف
generateAuthenticationToken
generateToken
الحصول على
getAvailableProductSet
insert
قائمة
revokeToken
setAvailableProductSet
تحديث

---

كجزء من تحسينات تسجيل الأجهزة، نحن بصدد الانتقال إلى استخدام حسابات Google المُدارة لجميع أجهزة Android Enterprise التي يستخدمها موظف لديه هوية مؤسسية.

بالنسبة إلى عمليات التسجيل الجديدة، ننصحك الآن باستخدام حسابات Google المُدارة بدلاً من حسابات Google Play للأعمال. في حين أنّنا سنواصل دعم حسابات Google Play للأعمال للمستخدمين الحاليين، فإنّها لا توفّر إمكانية الوصول إلا إلى متجر Google Play للأعمال. تمنح حسابات Google المُدارة المستخدمين إمكانية الوصول إلى مجموعة خدمات Google الكاملة والميزات التي تعمل من خلال جهاز آخر.

تحسينات التسجيل

تثبت حسابات Google المُدارة هوية المستخدم لدى Google. ويتيح ذلك تجارب تعمل من خلال جهاز آخر، مثل نقل المهام والإشعارات والمشاركة عن قرب. تزداد أهمية هذه الميزات في المؤسسات، حيث يستخدم المستخدمون غالبًا أجهزة متعدّدة.

ننصح المؤسسات التي لا تستخدم Google كموفّر للهوية بشدة بربط موفّر الهوية الحالي بـ Google. يتيح ذلك إنشاء حسابات Google مُدارة للموظفين أثناء عملية الربط. على المؤسسات استخدام موفّر الهوية نفسه الذي تستخدمه مع إدارة الخدمات الجوّالة للمؤسسات.

لقد أجرينا التغييرات التالية:

• تتولّى Google/Android الآن مصادقة المستخدم النهائي أثناء تسجيل الجهاز. تتطلّب وحدة التحكُّم بسياسة الجهاز (DPC) التابعة لإدارة الخدمات الجوّالة للمؤسسات أن تصادق Android المستخدم في النقطة المناسبة، ثم تعرض Android هوية المستخدم الذي سجّل الدخول على وحدة التحكُّم بسياسة الجهاز.

• على إدارة الخدمات الجوّالة للمؤسسات تمرير رمز تسجيل إلى Android عند طلب مصادقة المستخدم. يتم عرض هذا الرمز المميز من خلال طلب بيانات من واجهة برمجة التطبيقات إلى Android Enterprise API وقد يكون مشفّرًا ضمن حمولة تسجيل رمز الاستجابة السريعة أو الاتصال القريب المدى أو إعداد الأجهزة الجوّالة للمؤسّسات دفعةً واحدة.

في حين أنّ Android تتولّى الآن المصادقة وتوفّر هوية المستخدم لإدارة الخدمات الجوّالة للمؤسسات، تظلّ إدارة الخدمات الجوّالة للمؤسسات مسؤولة عن ربط هوية المستخدم بالمجموعة أو الهيكل التنظيمي الصحيحَين. هذا الربط ضروري لتطبيق السياسات المناسبة على الجهاز. لذلك، على المؤسسات مواصلة ربط دليل مستخدمي مؤسستها بإدارة الخدمات الجوّالة للمؤسسات.

يمكن لمشرفي تكنولوجيا المعلومات تفعيل ميزة مصادقة المستخدم النهائي الجديدة التي توفّرها Google أو إيقافها. لتزويد المستخدمين بأفضل تجربة، بما في ذلك الميزات التي تعمل من خلال جهاز آخر، ننصح مشرفي تكنولوجيا المعلومات بربط دليل مستخدمي مؤسستهم بـ Google. بدون هذا الرابط، سيحصل المستخدمون على حسابات Google Play للأعمال ولن يتمكّنوا من الوصول إلى التجارب التي تعمل من خلال جهاز آخر.

من المتطلبات الجديدة لجميع حلول إدارة الخدمات الجوّالة للمؤسسات توفير معلومات إضافية عند إنشاء رموز التسجيل وتسجيل الدخول. على وجه التحديد، عليك الآن الإشارة إلى ما إذا كان الجهاز بدون مستخدم (مثل جهاز Kiosk أو جهاز مخصّص) أم لا.

المزايا

توفّر العملية الجديدة التحسينات الرئيسية التالية:

• تسجيل مبسّط: يقلّل عدد الخطوات اليدوية والتعقيد مقارنةً بالطُرق العادية.

• دعم حساب Google: يمكنك الآن استخدام حسابات Google مع جميع طُرق توفير الحسابات. يزيل ذلك الحاجة إلى حسابات Google Play للأعمال.

• تجربة مستخدم محسّنة: باستخدام حسابات Google المُدارة، يمكنك الحصول على تجربة Android أكثر ثراءً تتضمّن ميزات قوية تعمل من خلال جهاز آخر، مثل المشاركة والنسخ واللصق.

تنفيذ حسابات المستخدمين

للتعرّف على كيفية المتابعة باستخدام عملية التسجيل الجديدة هذه، يُرجى الاطّلاع على مقالة تنفيذ حسابات المستخدمين.

مراحل نشاط حسابات Google المُدارة

بالنسبة إلى المؤسسات التي تستخدم حسابات Google، تعكس حسابات المستخدمين في حلّ إدارة الخدمات الجوّالة للمؤسسات حسابات المستخدمين الحالية المرتبطة بخدمة Google أخرى (مثل Google Workspace). تكون هذه الحسابات googleManaged (الجدول 1) لأنّ خدمات Google الخلفية هي مصدر إنشاء الحساب والمعلومات عنه.

بصفتك مزوّد حلّ إدارة الخدمات الجوّالة للمؤسسات، يمكنك توفير آليات في وحدة تحكّم المشرف في Google لتسهيل إنشاء حسابات المستخدمين المخزّنة في نظامك ومزامنتها المستمرة مع مصادر حسابات نطاق Google باستخدام أدوات مثل أداة مزامنة دليل Google Cloud (GCDS) وAdmin SDK Directory API. للحصول على نظرة عامة على الطرق المختلفة، يُرجى الاطّلاع على مقالة نظرة عامة على طرق توفير الهوية. يتطلّب نموذج هوية النطاق المُدار من Google أن يكون حساب المستخدم موجودًا في سياق الحلّ (وحدة تحكّم إدارة الخدمات الجوّالة للمؤسسات أو خادم إدارة الخدمات الجوّالة للمؤسسات أو ربما في مخزن بيانات) قبل أن يتم توفيره على أيّ من أجهزة المستخدم في سياق ملف العمل.

أثناء توفير الهوية، تتم تعبئة نطاق Google المُدار للمؤسسة بحسابات المستخدمين. في بعض الحالات، تتم مزامنة الهويات الحالية للمستخدمين على الإنترنت (مثل حسابات Microsoft Exchange) مع حساباتهم على Google.

مزامنة حسابات العملاء

في عملية نشر حسابات Google، يمكن للمؤسسة استخدام أداة مزامنة دليل Google Cloud لمزامنة البيانات في نطاق Google Workspace مع البيانات في دليل LDAP. بدلاً من ذلك، يمكنك استخدام أداة مزامنة دليل Google Cloud لإجراء ذلك نيابةً عن المؤسسة، إذا منحتك المؤسسة إذن الوصول.

تستدعي أداة مزامنة دليل Google Cloud واجهة برمجة تطبيقات دليل Google وتزامِن أسماء المستخدمين، ولكن ليس كلمات المرور.

إذا كانت المؤسسة تستخدم Microsoft Active Directory وأرادت الإبقاء على مزامنة كلمات مرور Google Workspace مع كلمات مرور Active Directory، يُرجى الاطّلاع على مقالة الاستعداد لاستخدام مزامنة كلمة المرور.

للاطّلاع على تعليمات أداة مزامنة دليل Google Cloud للمشرفين، يُرجى الاطّلاع على مقالة لمحة عن أداة مزامنة دليل Google Cloud.

Google Directory API

في عملية نشر حسابات Google، يمكنك استخدام Google Directory API لمزامنة الأدلة النشطة أو كلمات المرور أو كليهما:

• استخدام Directory API لمزامنة الدليل فقط إذا كان لديك إذن الوصول للقراءة فقط إلى نطاق Google المُدار للمؤسسة، يمكنك استخدام Google Directory API للحصول على معلومات حساب Google، مثل أسماء المستخدمين (ولكن ليس كلمات المرور) من Google. بما أنّه لا يمكنك كتابة أيّ بيانات في حسابات Google للمستخدمين، تكون المؤسسة مسؤولة بالكامل عن مراحل نشاط الحسابات.

  يصف السيناريو 1 وسيناريوهات مصادقة الدخول المُوحَّد المستنِد إلى SAML هذه الحالة بشكلٍ كامل.

  للحصول على معلومات عن استخدام Directory API بهذه الطريقة، يُرجى الاطّلاع على مقالة استرداد جميع مستخدمي الحساب في مستندات Directory API.

• استخدام Directory API لمزامنة الدليل وكلمة المرور الاختيارية إذا كان لديك إذن الوصول للقراءة والكتابة إلى نطاق Google المُدار للمؤسسة، يمكنك استخدام Google Directory API للحصول على أسماء المستخدمين وكلمات المرور ومعلومات حساب Google الأخرى. يمكنك تعديل هذه المعلومات ومزامنتها مع قاعدة البيانات الخاصة بك، وقد تكون مسؤولاً بشكلٍ كامل أو جزئي عن مراحل نشاط الحسابات، وذلك حسب الحلّ المقترَح الذي تقدّمه لعميلك.

  يصف السيناريو 2 هذه الحالة بشكلٍ كامل.

  لمزيد من المعلومات عن استخدام Directory API لإدارة معلومات حسابات المستخدمين، يُرجى الاطّلاع على دليل المطوّرين Directory API: حسابات المستخدمين.

سيناريوهات حسابات Google

في القسم التالي، يتم وصف بعض السيناريوهات النموذجية لتوفير الهوية في حسابات Google.

السيناريو 1: العميل مسؤول عن مراحل نشاط الحسابات

في هذا السيناريو، ينشئ عميلك حسابات Google لمستخدميه ويحتفظ بها.

يمكنك الحصول على معلومات حسابات المستخدمين من دليل LDAP الخاص بالمؤسسة، وربطها بالبيانات في حساب Google التي تحصل عليها من Google باستخدام Google Directory API.

تكون المؤسسة مسؤولة بالكامل عن مراحل نشاط الحسابات. على سبيل المثال، عند إنشاء حساب Google جديد، تضيف المؤسسة المستخدم إلى دليل LDAP. في المرة التالية التي تتم فيها مزامنة قاعدة البيانات مع دليل LDAP، تتلقّى قاعدة البيانات معلومات عن هذا المستخدم الجديد.

في هذا السيناريو:

• لديك إذن الوصول للقراءة فقط إلى حسابات Google.
• تحصل قاعدة البيانات على أسماء حسابات Google، ولكن ليس أسماء مستخدمي LDAP أو كلمات المرور.
• يمكنك استخدام Google Directory API للحصول على معلومات الحساب الأساسية لمستخدمي عميلك. (المعلومات المتاحة لك هي المعلومات غير القابلة للكتابة التي يعرضها طلب Users.get ). يمكنك استخدام هذه المعلومات للتأكّد من أنّ حسابات Google للمستخدمين موجودة حتى يتمكّن المستخدمون من المصادقة على أجهزتهم.
• يستخدم عميلك أداة مزامنة دليل Google Cloud لإجراء مزامنة أحادية الاتجاه لتعبئة حسابات Google للمستخدمين. (من المحتمل أيضًا أن تستخدم المؤسسة أداة مزامنة دليل Google Cloud للمزامنة المستمرة الخاصة بها بعد اكتمال توفير الهوية). اختياريًا، يمكن للمؤسسة أيضًا استخدام أداة GSPS لمزامنة ليس فقط أسماء المستخدمين، بل أيضًا كلمات المرور.

السيناريو 2: إدارة الخدمات الجوّالة للمؤسسات مسؤولة عن مراحل نشاط الحسابات

في هذا السيناريو، تتولّى عملية إنشاء حسابات Google نيابةً عن عميلك، وتكون مسؤولاً عن مراحل نشاط حسابات المستخدمين.

على سبيل المثال، عند تغيير معلومات المستخدم في دليل LDAP الخاص بالمؤسسة، تكون مسؤولاً عن تعديل حساب Google الخاص بالمستخدم. لا يتم استخدام أداة مزامنة دليل Google Cloud في هذا السيناريو.

في هذا السيناريو:

• لديك إذن الوصول للقراءة والكتابة إلى حسابات Google.
• تحصل قاعدة البيانات على أسماء حسابات Google وأسماء مستخدمي LDAP (ويمكنك الحصول اختياريًا على تجزئات كلمات المرور).
• يمكنك استخدام Google Directory API نيابةً عن عميلك لقراءة معلومات الحساب وكتابتها لمستخدمي المؤسسة. (المعلومات المتاحة لك هي المعلومات غير القابلة للكتابة التي يعرضها Users.get طلب). يمكنك استخدام هذه المعلومات للتأكّد من أنّ حسابات Google للمستخدمين موجودة حتى يتمكّن المستخدمون من المصادقة على أجهزتهم.
• لا يتم استخدام أداة مزامنة دليل Google Cloud.

ملاحظة: يمكنك مزامنة الحسابات في الوقت نفسه الذي تُعدّ فيه حسابات Google للمستخدمين. بهذه الطريقة، عندما تنشئ المؤسسة حسابات مستخدمي Android Enterprise لموظفيها، تتم مزامنة عناوين البريد الإلكتروني وكلمات مرور الشبكة الخاصة بالمستخدمين مسبقًا على أيّ حسابات يحتاج المستخدمون إلى الوصول إليها.

سيناريوهات مصادقة الدخول المُوحَّد المستنِد إلى SAML

في عملية نشر حسابات Google، قد تستخدم أنت أو عميلك لغة ترميز تأكيد الأمان (SAML) مع موفّر هوية لمصادقة حساب Google المرتبط بكل مستخدم. يمكنك استخدام أسماء حسابات Google كإثبات على أنّ حسابات Google للمستخدمين موجودة، وهو أمر ضروري لمصادقة المستخدم عند تسجيل الدخول إلى أجهزته. على سبيل المثال، يمكن استخدام SAML في السيناريو 2. لمعرفة تفاصيل حول كيفية إعداد ذلك، يُرجى الاطّلاع على مقالة لمحة عن الدخول المُوحَّد.