بروتوكولات الاتحاد وتوفير الحسابات

OIDC وOAuth وPKCE

تستخدم عملاء OIDC المسجلون تفويض المتصفح واختيار الحساب والموافقة والشروط عند تهيئتها. تفويض الجهاز واجهة مستقلة وليس بديلاً عن تسجيل العميل. يعتمد PKCE وخيارات التأكيد الأقوى على سياسة العميل والمؤسسة. ملفات PAR وprivate-key JWT وmTLS وDPoP وFAPI مشروطة؛ ووجودها في الشيفرة لا يعني تفعيلها.

1. سجل المصدر وإعادة التوجيه والاستجابة بدقة للعميل.
2. أكمل الموافقة واختيار الحساب وتحقق من الهوية والجمهور.
3. أكد دعم PKCE والتأكيد في السياسة ولا تضعف التحقق لتجاوز الرفض.

SAML والخروج عن بعد

تعرض مسارات خدمة SAML ومزود الهوية بيانات وصفية ومسارات تأكيد عبر المتصفح. هيئ الاتصال من إدارة SAML. تحقق مع الشريك من المصدر والجمهور ووجهة الرد والتوقيع وشروط الوقت. الخروج منفصل؛ فإلغاء الجلسة محلياً لا يثبت حذف ملفات الارتباط أو الجلسات لدى كل طرف معتمد.

1. قارن بيانات الاتصال ومفتاح التوقيع والنقاط مع الشريك.
2. اختبر تأكيداً موقعاً وتحقق من المؤسسة والموضوع والعضوية والانتهاء.
3. استخدم أدوات الخروج المدعومة وميز بين الإلغاء المحلي والخروج لدى الشريك.

SCIM ومزامنة الدليل

يختلف توفير الحسابات عن الاتحاد التفاعلي. يتكامل مخطط SCIM والمطابقة مع موصلات الدليل التي تستخدم وكيلاً مسجلاً لدى العميل. تحفظ الواردات مصدر المؤسسة وتعزل التعارضات؛ ولا يكفي البريد لربط الحسابات. لا يتضمن الخادم البرنامج التنفيذي لوكيل العميل.

1. سجل وجهة المؤسسة واربط السمات المدعومة ومفاتيح الهوية الثابتة.
2. نفذ مزامنة مضبوطة وافحص النتائج وعالج العناصر المعزولة ضمن مسار المؤسسة.
3. انشر الوكيل المتوافق وسجله على حدة قبل وضع عمل الموصل في الانتظار.

CAS وWS-Federation وRADIUS

يتطلب CAS تفعيلًا صريحاً. يظل WS-Federation وWS-Trust معطلين ما لم يسمح بهما تسجيل أو سياسة معتمدة؛ وتظل فحوص المجال والجمهور والرد والعضوية والتوقيع والانتهاء إلزامية. يستخدم RADIUS وكيلاً موقعاً اختيارياً وليس مستمعاً على الموقع. يفضل المرجع المعتمد RADIUS/1.1 عبر TLS أو DTLS؛ أما UDP القديم فللتوافق داخل الشبكات الخاصة فقط.

1. تحقق من تفعيل البروتوكول وتسجيل العميل قبل اختبار CAS أو WS-Federation.
2. في RADIUS أكد وكيل العميل وموصل المؤسسة والنقل المسموح.
3. إذا كان معطلاً أو غير مسجل، أكمل الإعداد ولا تبدل البروتوكول لتجاوز السياسة.

التسجيل وبيانات الاعتماد

يجب أن يظل تسجيل العميل ضمن المؤسسة والتطبيق المالكين له. تصف مراجع التسجيل الديناميكي وprivate-key JWT وmTLS وFAPI عقوداً مشروطة لا تفعيلًا عاماً. احتفظ بالمفاتيح الخاصة لدى مالكها ودوّر بيانات الاعتماد أو ألغها من أداة الإدارة المناسبة. مفاتيح الوكيل ليست بيانات اعتماد عميل OAuth.

1. اجمع المالك والمؤسسة وإعادة التوجيه أو البيانات الوصفية والنطاقات ونوع بيانات الاعتماد.
2. خزّن أي سر معاد بأمان ودوّره أو ألغِه عبر الإدارة.
3. لتسجيل الوكيل، أنشئ المفتاح الخاص لدى العميل وأرسل CSR.

العقد واستكشاف الأعطال

استخدم /api/auth/management/openapi.json لمعرفة عمليات الإدارة وحقولها وأمنها الحالية. وتشرح ملاحظات البروتوكول المعتمدة سلوك الموصلات والتأكيد المحدد. تشمل أسباب الفشل الشائعة اختيار مؤسسة خاطئة أو إعادة توجيه غير مسجلة أو بيانات أو شهادة قديمة أو ملف معطل أو توقيع غير صالح أو عزل SCIM أو وكيل ملغى. عالج حد الثقة المعني ولا توقف التحقق.

1. افحص مخطط OpenAPI ومتطلبات أمان العملية.
2. قارن تفاصيل الخطأ الآمنة والقيم المسجلة ببيانات المزود الحالية.
3. أعد اختبار المسار المضبوط وأكد الهوية أو حالة المزامنة قبل الإطلاق.

الأسئلة الشائعة

صفحات ذات صلة

• الدخول الموحد والهوية
• إدارة SSO
• حوكمة الهوية والوصول المميز
• الوصول إلى التطبيقات الخاصة