✖
 
     

    تكوين OAuth أو OpenID Connect لـ applicationات مخصصة

    يدعم ADSelfService Plus تسجيل الدخول الموحّد (SSO) إلى أي application مؤسسي مخصص مُمكّن عبر OAuth أو OpenID Connect. في هذا المستند، ستجد خطوات تكوين SSO المستند إلى OpenID Connect لـ application مخصصة.

    خطوات إنشاء application مخصص في ADSelfService Plus

    المتطلبات الأساسية

    1. سجّل الدخول إلى موفّر الخدمة (SP) باستخدام بيانات اعتماد المسؤول. SP هو application المخصّص الذي تريد تكوين OpenID Connect له.
    2. انسخ عناوين URL لإعادة التوجيه أو رد الاتصال للتفويض من موفر الخدمة.

    خطوات الإعداد

    1. سجّل الدخول إلى ADSelfService Plus باستخدام بيانات اعتماد المسؤول.
    2. انتقل إلى التكوين > الخدمة الذاتية > مزامنة كلمة المرور/تسجيل الدخول الموحّد.
    3. انقر فوق إضافة تطبيق.
    4. انقر على خيار التطبيق المخصص في الجزء الأيسر.
    5. أدخل اسم ووصف مناسبين لـapplication.
    6. أدخل اسم النطاق لحساب application الخاص بك. على سبيل المثال، إذا كان اسم المستخدم لديك هو johndoe@thinktodaytech.com، فإن thinktodaytech.com هو اسم النطاق الخاص بك.
    7. اختر السياسات التي تريد تعيينها من القائمة المنسدلة تعيين السياسات.
    8. يمكنك أيضًا إضافة أيقونة صغيرة أو كبيرة لـapplication، إذا رغبت.
    9. ضمن علامة تبويب SSO، حدد تمكين تسجيل الدخول الموحد.
    10. من القائمة المنسدلة تحديد طريقة تسجيل الدخول، اختر OAuth/OpenID Connect.
    11. من القائمة المنسدلة تدفق SSO المدعوم، اختر البدء من موفّر الخدمة أو البدء من موفّر الهوية.
      12. ملاحظة: يُنصح بالتواصل مع فريق دعم SP application الخاص بك والتحقق من التدفق(ات) المدعومة لـ SSO قبل اختيار تدفق SSO المدعوم.

      عند اختيار التدفق الذي يبدأ من موفّر الخدمة

      اختيار التدفق الذي يبدأه موفّر الخدمة من القائمة المنسدلة لتدفق SSO المدعوم.

      شكل 1: اختيار التدفق الذي يبدأه مزود الخدمة (SP-Initiated) من القائمة المنسدلة لتدفقات SSO المدعومة لتحديد كيفية بدء طلب SSO بواسطة مزود الخدمة.

      1. أدخل عنوان URL لصفحة تسجيل الدخول لموفر الخدمة في حقل SP Login Initiate URL.
      ملاحظة: تتطلب بعض التطبيقات بدء عملية تسجيل الدخول من صفحة تسجيل الدخول الخاصة بها، وهو ما يُعرف بتسجيل الدخول الذي يبدأه SP. يُوجَّه المستخدمون أولاً إلى صفحة تسجيل الدخول الخاصة بالتطبيق، والمحددة في حقل عنوان URL لبدء تسجيل الدخول بواسطة SP، ثم يعيد SP توجيههم إلى ADSelfService Plus، موفر الهوية (IdP) للمصادقة.

      في حال اختيار التدفق الذي يبدأه مزوّد الهوية (IdP)

      اختيار التدفق الذي يبدأه موفّر الهوية (IdP) من القائمة المنسدلة لتدفقات SSO المدعومة.

      الشكل 2: اختيار التدفق الذي يبدأ من موفّر الهوية (IdP-Initiated) من القائمة المنسدلة "تدفق SSO المدعوم" لتحديد كيفية بدء طلب SSO بواسطة موفّر الهوية.

    • في حقل عنوان URL لبدء تسجيل الدخول الخاص بـ IdP، أدخل عنوان application URL الخاص به الذي يرسل IdP إليه id_token، مما يمكّن SP من إكمال عملية تسجيل الدخول. بعد تكوين هذا العنوان، سيتمكن المستخدمون من تسجيل الدخول إلى application بالنقر على ذلك application المحدد في بوابة مستخدم ADSelfService Plus.
  • في حقل عناوين URL لإعادة توجيه SSO، أدخِل كل عناوين إعادة توجيه التفويض أو عناوين URL للاستدعاء المتاحة التي حصلت عليها من مزوّد الخدمة (SP) لديك في الخطوة 2 من المتطلبات المسبقة. يمكن العثور على هذه العناوين في صفحة تكوين SSO لـ OAuth/OIDC لدى مزوّد الخدمة.
  • من القائمة المنسدلة مصادقة العميل، اختر طريقة مصادقة العميل وفقًا لمتطلبات مزود الخدمة (SP). يحدد هذا الإعداد كيفية قيام موفر الهوية (IdP) بمصادقة طلب رمز الوصول الخاص بمزود الخدمة (SP).

    • اختيار وضع مصادقة العميل للتحقق من صحة طلب رمز الوصول الخاص بموفّر الخدمة.

    الشكل 3: اختيار وضع مصادقة العميل المناسب من القائمة المنسدلة لتحديد كيفية قيام IdP بمصادقة طلب رمز الوصول الخاص بـ SP.

    • سر العميل: وضع موحد يتضمن الأساليب التالية:
      • سر العميل الأساسي: يقوم SP بترميز client_id وclient_secret بترميز Base64 وإدراجهما في رأس Authorization لطلب رمز الوصول.
      • إرسال سر العميل: يقوم مزود الخدمة بتضمين client_id و client_secret في نص الطلب عند إرسال طلب الحصول على رمز الوصول.
      • JWT سرّ العميل: يقوم مزود الخدمة (SP) بإنشاء رمز JWT (JSON Web Token) باستخدام client_secret لتوقيع الطلب رقمياً.

      يقوم IdP بالتحقق من صحة بيانات الاعتماد أو التوقيع لتخويل الطلب.

      تحديد وضع المصادقة باستخدام سر العميل لمصادقة طلب رمز الوصول الخاص بمزود الخدمة.

      الشكل 4: اختيار وضع المصادقة باستخدام سرّ العميل.

    • JWT بالمفتاح الخاص: يقدم مزود الخدمة (SP) عنوان URL لـ JWKS (مجموعة مفاتيح الويب لـ JSON) يحتوي على مفتاحه العام. أثناء طلبات رمز الوصول، يستخدم مزود الخدمة مفتاحه الخاص لتوقيع رمز JWT. يتحقق مزود الهوية (IdP) من هذا التوقيع باستخدام المفتاح العام الذي تم الحصول عليه من عنوان URL لـ JWKS.
    • بلا: لا تتضمن مصادقة للعميل، مما يجعل هذا الخيار مناسباً لـ application أحادية الصفحة التي لا يمكنها تخزين أسرار العميل بشكل آمن. إذا تم اختيار هذا الخيار، فإن PKCE (مفتاح إثبات لتبادل الرموز)يتم اختياره تلقائياً ويصبح إلزامياً لمزيد من الأمان. تأكد من أن application العميل يدعم PKCE لإكمال مصادقة المستخدم بنجاح.

      • اختيار وضع مصادقة العميل None لمصادقة طلب رمز الوصول الخاص بمزود الخدمة (SP).

      الشكل 5: تحديد وضع مصادقة العميل None.

  • فعّل خانة الاختيار فرض PKCE للتحقق لتعزيز الأمان أثناء عملية التحقق من طلب الرمز المميز. ينطبق هذا الخيار على جميع أوضاع مصادقة العميل باستثناء None.

    • فرض استخدام PKCE للتحقق في وضع JWT باستخدام سر العميل/المفتاح الخاص.

    الشكل 6: إلزام استخدام PKCE لتعزيز الأمان أثناء عملية التحقق في وضع JWT بسر العميل/المفتاح الخاص.

  • عند اختيار Private Key JWT كطريقة لمصادقة العميل، سيحتاج ADSelfService Plus إلى تفاصيل JWKS URL من مزود الخدمة (SP) للحصول على المفتاح العام، والذي سيُستخدم بعد ذلك للتحقق من التوقيع.

    • اختيار وضع مصادقة العميل Private Key JWT لمصادقة طلب رمز الوصول الخاص بـ SP.

    الشكل 7: اختيار وضع مصادقة العميل باستخدام JWT بالمفتاح الخاص.

  • من قائمة خوارزمية المفتاح المنسدلة، اختر الخوارزمية المناسبة: HS256, RS256, RS384, أو RS512.

    • ملاحظة: إن خوارزمية المفتاح هي الخوارزمية المستخدمة لتوقيع الرموز، مثل id_token أو access_token. يضمن استخدام خوارزمية لتوقيع الرموز سلامة الرموز وأصالتها.

    اختيار خوارزمية المفتاح للتوقيع على رمز الوصول.

    الشكل 8: اختيار الخوارزمية المناسبة للمفتاح (HS256، RS256، RS384، أو RS512) من القائمة المنسدلة لتحديد كيفية توقيع رمز الوصول.

    HS256: خوارزمية متماثلة تستخدم سراً مشتركاً واحداً (أي client_secret الذي يتم إنشاؤه أثناء إنشاء application مخصص في IdP)، لتوقيع الرمز المميز والتحقق من صحته بدلاً من استخدام زوج مفاتيح عام/خاص.

    RS256: توقيع RSA مع SHA-256. وهي خوارزمية غير متماثلة تستخدم زوج مفاتيح عام/خاص يتم إنشاؤه وإدارته بواسطة IdP (يستخدم IdP المفتاح الخاص لإنشاء التوقيع، وتستخدم application مفتاحاً عاماً للتحقق من صحة التوقيع).

    RS384: مماثلة لـ RS256، باستثناء أنها تستخدم خوارزمية التجزئة SHA-384 لإنشاء توقيع RSA.

    RS512: مماثلة لـ RS256، باستثناء أنها تستخدم خوارزمية التجزئة SHA-512 لإنشاء توقيع RSA.

  • يكون حقل صلاحية رمز الوصول مضبوطًا افتراضيًا على 3600 ثانية. يمكنك تغيير هذه القيمة إذا لزم الأمر.

    • ملاحظة: صلاحية رمز الوصول تحدد المدة الزمنية التي سيكون خلالها الرمز المرسل من قبل موفّر الهوية (IdP) متاحًا لموفّر الخدمة (SP).

  • انقر على مربع الاختيار السماح برمز التحديث للسماح لموفّر الخدمة (SP) بالحصول على رموز الوصول من دون مطالبة المستخدم بإعادة المصادقة في كل مرة.
  • انقر فوق التكوين المتقدم في الزاوية العلوية اليمنى.
  • ضمن تكوين سمات مطالبات OAuth/OpenID Connect، قم بتعيين السمات وفقًا لمتطلباتك.

    • تعيين سمات المطالبات ضمن تكوين OAuth/OpenID Connect.

    الشكل 9: تعيين سمات المستخدم ضمن تكوين سمات المطالبات لـ OAuth/OpenID Connect.

  • انقر على إنشاء تطبيق مخصص.

    • يمكن للمستخدمين الذين تنطبق عليهم السياسات التي اخترتها في الخطوة 7 الآن تسجيل الدخول إلى application المخصص من خلال بوابة المستخدم الخاصة بهم باستخدام SSO.

    الانتقال إلى الأعلى

    شكرًا!

    تم إرسال طلبك إلى فريق الدعم الفني لدى ADSelfService Plus. سيقوم موظفو الدعم الفني لدينا بمساعدتك في أقرب وقت ممكن.

     

    هل تحتاج إلى مساعدة تقنية؟

    • أدخل عنوان بريدك الإلكتروني
    • تحدث إلى الخبراء
    •  
       
    •  
    • بالنقر على 'تحدث إلى الخبراء' فإنك توافق على معالجة البيانات الشخصية وفقاً لـ سياسة الخصوصية.

    لا ترى ما تبحث عنه؟

    •  

      قم بزيارة مجتمعنا

      اطرح أسئلتك في المنتدى.

       
    •  

      اطلب موارد إضافية

      أرسل إلينا متطلباتك.

       
    •  

      هل تحتاج إلى مساعدة في التنفيذ؟

      جرّب OnboardPro