إدارة موفري الهوية
كوّن موفري هوية مخصصين (IdPs) لتسجيل الدخول الموحد SAML أو OIDC حتى يتمكن مستخدمو مؤسستك من المصادقة ببيانات اعتمادهم المؤسسية الحالية.
إدارة موفر الهوية متاحة لمسؤولي الخطة المؤسسية فقط.
كوّن موفر هوية مخصص (IdP) لتمكين تسجيل الدخول الموحد (SSO) لمؤسستك. عند تكوين IdP، يُعيد Bob توجيهك إليه للمصادقة عند تسجيل الدخول إلى IBM Bob عبر بيئة التطوير وBob Shell وBob Web.
يمكنك تكوين موفري هوية SAML وOpenID Connect (OIDC) مع Bob. استخدم البروتوكول الذي يطابق منصة الهوية الخاصة بمؤسستك.
توافق بروتوكولات SSO
IBM Bob متوافق مع بروتوكولات SSO التالية:
- SAML (Security Assertion Markup Language)
- OIDC (OpenID Connect)
موفرو OIDC المُتحقَّق منهم
بينما يمكنك استخدام موفري OIDC آخرين يستوفون متطلبات التكوين والـ token، فإن المنصات التالية مُتحقَّق منها:
- Auth0
- Keycloak
- Okta
- PingOne
إضافة موفر هوية
إضافة IdP هي عملية من خطوتين. أولاً، تُكوِّن IdP وتحفظه. ثم تضيف نطاقات البريد الإلكتروني التي تستخدمه.
الخطوة 1: تكوين موفر الهوية
أدخل اسماً للـ IdP.
اختر نوع IdP: SAML أو OIDC.
أنشئ بيانات اعتماد مزود الخدمة (SP).
يتطلب Bob مفتاحاً خاصاً لـ SP وشهادة SP لتوقيع طلبات مصادقة SAML. يجب عليك إنشاء هذه بنفسك باستخدام أداة سطر الأوامر openssl.
إذا كان لديك بالفعل زوج مفاتيح SP وشهادة، تخطَّ إلى الخطوة التالية.
نفّذ الأمر التالي لإنشاء المفتاح الخاص لـ SP:
openssl genrsa -out sp_private_key.pem 2048ثم نفّذ هذا الأمر لإنشاء شهادة SP من المفتاح الخاص. استبدل قيم /CN و/O و/C باسم شهادة وصفي واسم مؤسستك ورمز بلدك المكون من حرفين:
openssl req -new -x509 -key sp_private_key.pem -out sp_certificate.pem -days 365 -subj "/CN=Bob SAML SP/O=IBM/C=US"يجب أيضاً رفع ملف sp_certificate.pem إلى IdP الخاص بك حتى يتمكن من التحقق من التوقيعات على الطلبات الواردة من Bob.
أدخل تفاصيل التكوين لـ IdP.
راجع المتطلبات الخاصة بالبروتوكول في الأقسام التالية.
انقر على Save.
يُنشأ IdP ويظهر في الجدول في تبويب Authentication.
تكوين SAML
يتطلب SAML تفاصيل التكوين التالية:
حقول موفر الهوية — احصل عليها من IdP الخاص بك:
idp_entity_id— المعرف الفريد للـ IdP (مثلاً،https://idp.example.com)idp_sso_url— عنوان URL لـ SSO حيث يُرسل Bob طلبات المصادقةidp_certificate— شهادة X.509 المُرمَّزة بـ PEM المستخدمة للتحقق من استجابات SAML من IdP
حقول مزود الخدمة — استخدم الملفات المُنشأة في الخطوة السابقة:
sp_private_key— محتوىsp_private_key.pemsp_certificate— محتوىsp_certificate.pem
الحقول الاختيارية:
idp_slo_url— عنوان URL لـ Single Logout للـ IdP. تسجيل الخروج الفردي غير مُنفَّذ بالكامل بعد في Bob.
في قسم Attribute mapping، حدد خرائط سمات المستخدم في IdP إلى حقول مستخدم IBM Bob. تنسيق الخريطة هو اسم سمة Bob → اسم سمة IdP أو URI. تحقق من تكوين IdP للحصول على أسماء السمات الصحيحة.
email(مطلوب) — عنوان البريد الإلكتروني للمستخدمname(اختياري) — الاسم الكامل للمستخدمgiven_name(اختياري) — الاسم الأول للمستخدمfamily_name(اختياري) — اسم العائلة للمستخدمgroups(اختياري) — مجموعات المستخدم انقر على Save.
مسؤول IdP: تسجيل عميل OIDC جديد
قبل أن يتمكن مسؤول مثيل Bob من تكوين سجل OIDC IdP في Bob، يجب على مسؤول IdP أولاً إنشاء تطبيق OIDC (عميل) داخل موفر الهوية. القيم الناتجة من هذه الخطوة هي التي يقدّمها مسؤول مثيل Bob عند إضافة IdP في Bob.
التطبيق ونوع المنح
أنشئ Web application (عميل سري من جهة الخادم) في موفر الهوية وفعّل نوع منح Authorization Code. يستخدم Bob تدفق Authorization Code حصراً؛ لا تختر Implicit أو Device Code أو Client Credentials.
Redirect URI
سجّل عنوان callback التالي في تطبيق OIDC. يطبّق معظم الموفرين مطابقة نصية صارمة، لذا انسخه كما هو:
https://api.us-east.bob.ibm.com/authn/v1/auth/callbackالنطاقات التي يجب تفعيلها للعميل
| النطاق | الغرض | مطلوب |
|---|---|---|
openid | يفعّل وضع OIDC ويعيد id_token | نعم |
email | يتيح عنوان البريد الإلكتروني للمستخدم في id_token أو عبر نقطة نهاية userinfo | نعم |
offline_access | يمنح refresh_token مع access token | نعم لمعظم الموفرين |
يتطلب Bob وجود refresh_token في كل استجابة لتبادل Authorization Code. إذا كان موفرك يصدر refresh tokens بآلية مختلفة، فاضبطه وفقاً لذلك، مع التأكد من السماح للعميل بتلقيها. إذا لم يُعَد refresh_token، يُلغى تسجيل الدخول.
أسلوب مصادقة Token endpoint
اضبط أسلوب المصادقة لـ token endpoint في تطبيق OIDC على client_secret_post. يرسل Bob client_id وclient_secret كمعاملات في متن النموذج لكل طلب token. لا تُقبَل client_secret_basic وprivate_key_jwt وnone.
إعدادات الـ token
| الإعداد | القيمة المطلوبة |
|---|---|
| تنسيق access token | أيّاً كان (JWT أو opaque؛ لا يحلل Bob access token الخاص بـ IdP مباشرةً) |
| ID token | يجب إصداره في كل تبادل لـ Authorization Code وكل تجديد للـ token |
| خوارزمية توقيع ID token | RS256 أو ES256 أو PS256 |
| تدوير Refresh token | يمكنك استخدام تدوير refresh token. يخزن Bob الـ token الجديد عند كل تجديد. إذا كان موفرك يدوّر refresh tokens، فتأكد من أن الموفر يُبطل الـ token السابق فقط بعد استلام Bob البديل. |
القيم التي تُسلَّم لمسؤول مثيل Bob
بعد إنشاء تطبيق العميل، قدّم القيم التالية لمسؤول مثيل Bob:
| القيمة | مكان العثور عليها | حقل تكوين Bob |
|---|---|---|
| Client ID | صفحة بيانات اعتماد التطبيق | client_id |
| Client Secret | صفحة بيانات اعتماد التطبيق | client_secret |
| Authorization Endpoint URL | صفحة نقاط نهاية OIDC للموفر أو .well-known/openid-configuration | authorization_endpoint |
| Token Endpoint URL | صفحة نقاط نهاية OIDC للموفر أو .well-known/openid-configuration | token_endpoint |
| JWKS URI | صفحة نقاط نهاية OIDC للموفر أو .well-known/openid-configuration | jwks_uri |
| Issuer URL | صفحة نقاط نهاية OIDC للموفر أو .well-known/openid-configuration | issuer |
| Userinfo Endpoint URL (اختياري) | صفحة نقاط نهاية OIDC للموفر أو .well-known/openid-configuration | userinfo_endpoint |
ينشر معظم الموفرين عناوين URL لنقاط النهاية في https://<your-provider-domain>/.well-known/openid-configuration.
تكوين OIDC
يمكنك استخدام اكتشاف موفر OIDC. انقر على زر Retrieve configuration لملء حقول نقاط النهاية تلقائياً من مستند الموفر .well-known/openid-configuration، أو أدخل كل عنوان URL يدوياً.
يتطلب OIDC تفاصيل التكوين التالية:
| الحقل | مطلوب | الوصف |
|---|---|---|
client_id | نعم | معرف العميل المسجل لدى موفر هويتك. |
client_secret | نعم | سر العميل للتطبيق المسجل. يُخزِّن Bob هذا بأمان ولا يُعيده أبداً في استجابات API. |
scopes | نعم | النطاقات المطلوبة أثناء تدفق التصريح. يجب أن تتضمن هذه القائمة openid. عادةً ما تتضمن أيضاً email والنطاق الخاص بالموفر المستخدم لإصدار refresh token، مثل offline_access. |
authorization_endpoint | نعم | عنوان URL للتصريح HTTPS الذي يُعيد Bob توجيه المستخدمين إليه لتسجيل الدخول. |
token_endpoint | نعم | عنوان URL للـ token HTTPS المستخدم لتبادل رمز التصريح بالـ tokens. |
jwks_uri | نعم | عنوان URL عبر HTTPS لمجموعة مفاتيح الويب JSON (JWKS) المستخدمة للتحقق من توقيع استجابات id_token. |
issuer | لا | معرف المُصدِر HTTPS لموفر الهوية. |
prompt | لا | قيمة prompt لـ OIDC المُمرَّرة إلى طلب التصريح. |
لا يستخدم OIDC Attribute mapping. يقرأ Bob عنوان البريد الإلكتروني للمستخدم مباشرةً من claim email في id_token.
مثال على تكوين OIDC
{
"authorization_endpoint": "https://corp.okta.com/oauth2/default/v1/authorize",
"token_endpoint": "https://corp.okta.com/oauth2/default/v1/token",
"issuer": "https://corp.okta.com/oauth2/default",
"client_id": "0oa1b2c3d4e5f6g7h8i9",
"client_secret": "super-secret-value",
"scopes": ["openid", "email", "offline_access"]
}متطلبات وقيود OIDC
- يتطلب Bob
refresh_tokenفي استجابة تبادل رمز التصريح. إذا لم يُعِد موفرك واحداً، يفشل تسجيل الدخول. - بالنسبة لمعظم الموفرين، إضافة
offline_accessإلىscopesهو ما يُشغِّل إصدار refresh token. بعض الموفرين يستخدمون سلوكاً مختلفاً، لذا تحقق من توثيق موفرك. - تسجيل الخروج back-channel لـ OIDC غير متاح.
- إذا غيّر موفرك عناوين URL لنقاط النهاية، حدّث تكوين IdP في Bob.
الخطوة 2: إضافة فلاتر النطاق
بعد حفظ IdP، أضف نطاقات البريد الإلكتروني التي يجب أن تستخدمه للمصادقة.
في تبويب Authentication، ابحث عن IdP الذي أنشأته للتو وافتح إعداداته.
في قسم Domain filters، أضف نطاقات البريد الإلكتروني التي يجب أن تستخدم هذا IdP. يُعاد توجيه المستخدمين الذين تطابق عناوين بريدهم الإلكتروني نطاقاً مُكوَّناً إلى هذا IdP عند تسجيل الدخول.
احفظ تغييراتك.
يمكن ربط كل نطاق بريد إلكتروني بـ IdP واحد فقط. إذا كان النطاق مستخدماً بالفعل من قِبَل IdP آخر، لا يمكن حفظ التكوين حتى يُحل التعارض. يجب أيضاً التحقق من كل نطاق قبل تطبيق SSO عليه. راجع التحقق من ملكية النطاق.
التحقق من ملكية النطاق
يتطلب IBM Bob التحقق من أن مؤسستك تمتلك كل نطاق قبل تطبيق SSO عليه. يتم التحقق بإضافة سجل DNS TXT إلى نطاقك.
اذهب إلى صفحة إدارة IBM Bob.
اختر تبويب Authentication.
اختر IdP الذي يحتوي على النطاق الذي تريد التحقق منه.
في قسم Domain filters، ابحث عن النطاق وانسخ رمز التحقق المعروض.
في موفر DNS الخاص بك، أضف سجل TXT إلى النطاق بالتنسيق التالي:
bob-verify=<verification-code>استبدل verification-code بالرمز المنسوخ من قسم Domain filters.
ارجع إلى تبويب Authentication وانقر على Check verification للنطاق.
تتحدث حالة التحقق من النطاق إلى Verified عندما يكتشف IBM Bob بنجاح سجل TXT. قد تستغرق تغييرات DNS وقتاً للانتشار.
إزالة موفر هوية
اذهب إلى صفحة إدارة IBM Bob.
اختر تبويب Authentication.
ابحث عن IdP الذي تريد إزالته وانقر على Delete.
في مربع حوار التأكيد، انقر على Confirm.
حذف IdP يُزيل تكوين SSO لجميع النطاقات المرتبطة. المستخدمون الذين اعتمدوا على هذا IdP للمصادقة سيحتاجون إلى تسجيل الدخول بطريقة أخرى. تظهر تحذير إذا كان IdP يحتوي على نطاقات مُتحقَّق منها.