إدارة المستخدمين

أدِر وصول المستخدمين لـ IBM Bob المحلي باستخدام Keycloak كمزوّد هوية، مع اتحاد LDAP أو Active Directory أو الحسابات المُدارة محليًا.

يشمل IBM Bob المحلي مزوّد هوية Keycloak لمصادقة المستخدمين وإدارة وصولهم. يمكن توفير المستخدمين من بيئة LDAP أو Active Directory موجودة أو إنشاؤهم مباشرةً في Keycloak. بصرف النظر عن طريقة توفيرهم، يجب تعيين دور Bob مناسب للمستخدمين قبل أن يتمكنوا من الوصول إلى الخدمة.

نظرة عامة

المفهومالوصف
مزوّد الهويةKeycloak — يُنشر ويُدار بواسطة مُشغِّل Bob.
مصادر المستخدمينيمكن إنشاء المستخدمين مباشرةً في Keycloak أو توفيرهم من خدمة LDAP أو Active Directory.
المصادقةيقوم المستخدمون بالمصادقة من خلال Keycloak باستخدام OpenID Connect (OIDC). يُصدر Keycloak رمز تفويض قصير الأجل تتبادله bob-authn للحصول على رمز حامل خاص بـ Bob.
التفويضيتحكم في الوصول إلى قدرات Bob الأدوار المعيَّنة للمستخدمين داخل Keycloak.
سطح التكوينيُدار تكامل LDAP من خلال المورد المخصص BobLDAP باستخدام الأمر bobctl configure-idp.

أنواع أدلة LDAP المدعومة

يدعم Bob المحلي أي خدمة دليل متوافقة مع LDAPv3. يُحدد المعامل vendor في تكوين LDAP قالب مزوّد Keycloak المُستخدَم، والذي يُعرّف الإعدادات الخاصة بالبروتوكول لنوع الدليل المحدد.

قيمة vendorنوع الدليل
otherOpenLDAP وخدمات الدليل الأخرى المتوافقة مع LDAPv3
adMicrosoft Active Directory
rhdsRed Hat Directory Server
tivoliIBM Security Directory Server (المعروف سابقًا بـ Tivoli Directory Server)
edirectoryNetIQ / Micro Focus eDirectory

معمارية المصادقة والاتحاد

عند تسجيل المستخدم الدخول، يمرر Bob الطلب إلى Keycloak، الذي يتولى المصادقة. يقوم جميع المستخدمين بالمصادقة من خلال Keycloak. اتحاد LDAP اختياري ونشط فقط عند تكوينه.

  • تفعيل اتحاد LDAP: يقوم Keycloak بمصادقة المستخدمين مباشرةً مقابل دليل LDAP. تظل كلمات مرور المستخدمين في دليل LDAP ولا يتم تخزينها في Keycloak.
  • تعطيل اتحاد LDAP: يقوم Keycloak بمصادقة المستخدمين باستخدام مخزن مستخدمي Keycloak المحلي.

تدفق المصادقة

  1. يُدخل المستخدم بيانات الاعتماد.
  2. يقوم Keycloak بمصادقة المستخدم.
  3. يُصدر Keycloak رمز تفويض قصير الأجل.
  4. تتبادل bob-authn رمز التفويض للحصول على رمز حامل خاص بـ Bob.
  5. تستخدم جميع طلبات واجهة برمجة التطبيقات (API) اللاحقة الرمز الصادر من Bob.

سلوك مزامنة المستخدمين

يدعم Bob المحلي وضعَين للمزامنة، مُكوَّنَين من خلال إعداد userSync.enabled في تكوين LDAP:

الوضعuserSync.enabledالسلوك
عند الطلبfalse (افتراضي)يُستورد المستخدمون في Keycloak فقط عند تسجيل دخولهم الأول بنجاح، مما يُلغي الحاجة إلى فحص مسبق للدليل. يُوصى بهذا الخيار لبيئات الدليل الكبيرة جدًا.
المزامنة السريعة (موصى به)trueعند تسجيل مزوّد LDAP، تستورد مزامنة كاملة لمرة واحدة جميع المستخدمين من الدليل. بعد الاستيراد الأولي، يُزامن Keycloak تحديثات المستخدمين تلقائيًا كل خمس دقائق. يضمن هذا النهج توافر جميع المستخدمين فورًا، ويمكن توفير حسابات المسؤولين المُحددة من خلال adminEmails دون مطالبة المستخدمين بتسجيل الدخول أولًا.

المزامنة عند الطلب

استخدم هذا الوضع للأدلة الكبيرة جدًا حيث لا يكون استيراد جميع المستخدمين فورًا أمرًا عمليًا.

أثناء محاولة المصادقة الأولى:

  1. يتم استيراد المستخدم إلى Keycloak.
  2. يتم توفير المستخدم في Bob من خلال SCIM.
  3. تفشل محاولة تسجيل الدخول الأولى بسبب زمن وصول التوفير.
  4. يمكن للمستخدم تسجيل الدخول بنجاح بعد اكتمال التوفير.

المزامنة السريعة

موصى به لمعظم عمليات النشر. يصبح جميع المستخدمين متاحين فور اكتمال المزامنة ولا يحتاجون إلى تسجيل الدخول ليتم توفيرهم.

ملاحظة:

فاصل المزامنة الزمني محدد حاليًا عند 5 دقائق.

مزامنة المستخدمين باستخدام SCIM

يستخدم IBM Bob المحلي مكوّن SCIM 2.0 مخصصًا مُضمَّنًا في Keycloak لمزامنة حسابات المستخدمين بين Keycloak وBob. يُكوّن مُشغِّل Bob هذا التكامل تلقائيًا، ولا يُلزم أي تكوين إضافي.

كيفية عمل مزامنة المستخدمين

عند وقوع حدث دورة حياة مستخدم في Keycloak، يُرسل مكوّن SCIM الحدث المقابل إلى خدمة bob-admin. يُحدّث Bob بعد ذلك وصول المستخدم ومعلومات ملفه الشخصي بناءً على الحدث.

تنطبق هذه المزامنة على جميع المستخدمين الذين يديرهم Keycloak، بما فيهم مستخدمو LDAP الموحَّدون والمستخدمون الذين أُنشئوا مباشرةً في وحدة تحكم إدارة Keycloak.

حدث المستخدمإجراء Bob
إنشاء المستخدم أو أول تسجيل دخولتوفير المستخدم ومنحه وصولًا إلى Bob
تحديث المستخدممزامنة تغييرات الملف الشخصي
حذف المستخدم من LDAPسحب الوصول إلى Bob مع الاحتفاظ ببيانات المستخدم
ملاحظة:

يؤدي حذف مستخدم من LDAP إلى سحب وصوله إلى Bob دون حذف بياناته. إذا أُعيد إضافة المستخدم إلى الدليل، يُستعاد وصوله ويبقى عمله السابق متاحًا.

التحقق من المزامنة

لا يوفر Bob حاليًا شرط حالة أو فحص صحة يؤكد نشاط مزامنة SCIM. للتحقق من أن التوفير يعمل، أنشئ أو استورد مستخدمًا تجريبيًا وتأكد من ظهوره في Bob بعد تسجيل دخوله الأول أو بعد الاستيراد الأولي لـ userSync.

إدارة الأدوار وعضوية المجموعات

يستخدم IBM Bob مجموعات Keycloak للتحكم في أدوار المستخدمين. يُنشئ مُشغِّل Bob المجموعات المطلوبة وتعيينات الأدوار ويحافظ عليها تلقائيًا.

مجموعة Keycloakالدور الممنوح في Keycloakمن يُضاف
bob-usersbob-userيُضاف جميع المستخدمين المصادق عليهم تلقائيًا عند أول تسجيل دخول ناجح من خلال المجموعة الافتراضية لـ realm.
bob-adminsbob-adminيُعيَّن المستخدمون المُحددون في حقل adminEmails من تكوين BobLDAP تلقائيًا بواسطة المُشغِّل في كل دورة تسوية.

وصول المسؤول

يحصل جميع المستخدمين المصادق عليهم على وصول قياسي إلى Bob.

لمنح امتيازات المسؤول:

  1. أضف عنوان البريد الإلكتروني للمستخدم إلى adminEmails في ملف تكوين موفر الهوية (IDP).
  2. طبّق التغيير: ./bobctl configure-idp --config my-idp.yaml

لسحب امتيازات المسؤول:

  1. أزل عنوان البريد الإلكتروني من adminEmails.
  2. أعد تطبيق التكوين.
مهم:

bobctl configure-idp هو الأسلوب المدعوم الوحيد لإدارة وصول مسؤولي Bob. إضافة عنوان بريد إلكتروني إلى adminEmails لا تنشئ حساب مستخدم — يجب أن يكون المستخدم موجودًا بالفعل في Keycloak من خلال اتحاد LDAP أو الإنشاء المباشر للمستخدم.

إدارة Keycloak

يشمل Bob المحلي نشر Keycloak الذي يوفر خدمات إدارة الهوية والوصول. إدارة Keycloak مستقلة عن إدارة Bob، وتخدم كل واجهة غرضًا مختلفًا.

واجهات الإدارة

الواجهةعنوان URLالغرض
وحدة تحكم إدارة Keycloakhttps://bob-keycloak.<namespace>.<ingress-domain>إدارة بنية Keycloak التحتية والمستخدمين والمجموعات ومزوّدي الهوية وإعدادات الاتحاد.
واجهة إدارة Bobhttps://bob.<namespace>.<ingress-domain>/adminإدارة مستخدمي Bob وأدوارهم والدعوات والإعدادات الخاصة بالمستأجر.

يُنشئ مُشغِّل Bob كلا المسارَين تلقائيًا أثناء التثبيت.

ملاحظة:

سجلات الأنشطة غير متوفرة في واجهة مستخدم إدارة Bob لهذا الإصدار. للوصول إلى سجلات الخدمة، اعرض سجلات الحاوية (pod logs) لخدمة المصادقة وخدمة التخويل وخدمة الإدارة مباشرةً من وحدة تحكم OpenShift Container Platform أو عبر واجهة سطر الأوامر (CLI). لمزيد من المعلومات، راجع القيود المعروفة.

الوصول إلى وحدة تحكم إدارة Keycloak

للعثور على مسار Keycloak في مجموعتك، شغّل:

oc get route -n <instance-namespace> | grep keycloak

استرجع بيانات اعتماد المسؤول الأولية من سر المجموعة:

oc get secret bob-keycloak-initial-admin \
  -n <instance-namespace> \
  -o jsonpath='{.data.username}' | base64 -d && echo
oc get secret bob-keycloak-initial-admin \
  -n <instance-namespace> \
  -o jsonpath='{.data.password}' | base64 -d && echo
تحذير:

لا تُعدّل سر bob-keycloak-initial-admin. يستخدم مُشغِّل Bob هذه البيانات أثناء التسوية. قد يُؤدي تغيير بيانات الاعتماد المخزَّنة إلى تعطيل الوظائف التي يديرها المُشغِّل.

إذا كنت بحاجة إلى حساب مسؤول شخصي، سجّل الدخول ببيانات اعتماد المسؤول الأولية وأنشئ مستخدمًا منفصلًا في realm master للمهام الإدارية الروتينية.

بعد تسجيل الدخول، انتقل إلى realm bob باستخدام منتقي realm في الزاوية العلوية اليسرى من وحدة تحكم Keycloak. يُدار جميع مستخدمي Bob ومجموعاتهم ومزوّدي الهوية وموفري الاتحاد من هذا realm.

فهم realms في Keycloak

realm هو نطاق إدارة معزول يحتوي على مستخدميه وبيانات اعتماده وأدواره ومجموعاته ومزوّدي هويته.

يستخدم Bob المحلي realmَين:

Realmالغرض
masterمحجوز لإدارة Keycloak. يستطيع المستخدمون في هذا realm إدارة Keycloak لكنهم لا يستطيعون الوصول إلى Bob.
bobيحتوي على جميع مستخدمي Bob ومجموعاتهم وموفري اتحاد LDAP وعملاء التطبيقات. يُنشئ مُشغِّل Bob هذا realm ويديره.

الـ realmان مستقلان تمامًا. العضوية أو الامتيازات في أحدهما لا تمنح وصولًا إلى موارد الآخر.

ملاحظة:

يُدار realm bob بواسطة المُشغِّل. يمكنك إجراء تغييرات مباشرة من خلال وحدة تحكم Keycloak، لكن دعم IBM يقتصر على حل المشكلات التي تؤثر على مصادقة Bob ووصوله.

إدارة موفري اتحاد LDAP

موفرو اتحاد LDAP المُكوَّنون من خلال bobctl configure-idp أو المورد المخصص BobLDAP مرئيون في قسم User Federation من realm bob.

يُسجّل مُشغِّل Bob موفري LDAP عند إنشائهم. التغييرات اللاحقة التي تُجرى مباشرةً في وحدة تحكم Keycloak لا تُزامَن مع المورد المخصص BobLDAP المقابل.

للإدارة المتسقة للتكوين، استخدم المورد المخصص BobLDAP وأوامر bobctl configure-idp كلما أمكن.

اعتبارات الأمان

اتّبع هذه التوصيات عند إدارة Keycloak:

  • قيّد الوصول إلى سر bob-keycloak-initial-admin على مسؤولي المجموعة.
  • نفّذ مهام إدارة Bob في realm bob.
  • استخدم realm master فقط لإدارة بنية Keycloak التحتية.
  • لا تُنشئ realmات أو عملاء إضافيين إلا إذا كان ذلك مطلوبًا صراحةً ومدعومًا.
  • أدِر اتحاد LDAP من خلال موارد BobLDAP بدلًا من تعديل إعدادات الموفر مباشرةً في وحدة تحكم Keycloak.
  • تعامل مع حساب المسؤول الأولي باعتباره حسابًا طارئًا أو تمهيديًا، واستخدم حسابات مسؤول شخصية مخصصة للإدارة الروتينية.

إدارة مستخدمي Keycloak المباشرين

يمكن إنشاء المستخدمين وإدارتهم مباشرةً داخل Keycloak دون دمج دليل LDAP. هذا النهج مناسب لبيئات إثبات المفهوم أو عمليات النشر الصغيرة أو التثبيتات التي لا يتوفر فيها خادم LDAP. لبيئات الإنتاج التي تستخدم بالفعل خدمة الدليل المؤسسي، يُعدّ اتحاد LDAP النهج الموصى به.

إضافة مستخدم

لإنشاء مستخدم محلي، افتح قسم Users في realm bob وأنشئ حساب مستخدم جديدًا. بعد حفظ المستخدم، هيّئ كلمة مرور وعيّن عضوية المجموعة المناسبة:

  • أضف المستخدم إلى bob-users لمنح الوصول القياسي.
  • أضف المستخدم إلى bob-users وbob-admins معًا لمنح وصول المسؤول.

إدارة كلمات المرور

تُدار كلمات مرور المستخدمين المُديرين محليًا من خلال وحدة تحكم إدارة Keycloak. افتح سجل المستخدم واستخدم علامة التبويب Credentials لإنشاء كلمة المرور أو تحديثها أو إعادة تعيينها.

إزالة مستخدم

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

ما رأيك في هذا الموضوع؟