إذن شفاف لتطبيق على Oracle Weblogic Server

في هذه المقالة ، سأخبرك كيف انتقلنا من ترخيص NTLM إلى تفويض Kerberos للتطبيقات على Oracle Weblogic Server ، وبالتالي تبسيط تسجيل دخول المستخدم من خلال إزالة الحاجة إلى إدخال كلمة مرور. جميع المستخدمين ، وكذلك خادم التطبيق ، موجودون في نفس المجال ؛ كما تم تكوين تفويض المجال لتطبيقات خادم Weblogic مسبقًا. تم التحقق من جميع التكوينات على WLS 12.1.2.

أولاً ، نظرية صغيرة ، لفترة وجيزة للغاية لفهم عملية التفاعل.

ما هو الدخول الموحد؟


الدخول الموحّد (SSO) هو آلية يسمح من خلالها إجراء مصادقة مستخدم واحد للمستخدم بالوصول إلى كافة أجهزة الكمبيوتر والأنظمة التي لديه إذن للوصول إليها دون الحاجة إلى إدخال عدة كلمات مرور. سيتم إعادة استخدام بيانات الاعتماد التي تم إدخالها مسبقًا بشفافية بواسطة المكونات المختلفة.

ما هو Kerberos؟


Kerberos هو بروتوكول مصادقة شبكة تم تطويره لأول مرة بواسطة معهد ماساتشوستس للتكنولوجيا. Kerberos هي طريقة آمنة لمصادقة طلب خدمة على الشبكة ومصممة لتوفير مصادقة قوية لتطبيقات خادم العميل باستخدام التشفير بمفتاح سري.

ما هو SPNEGO؟


SPNEGO هو محرك تفاوض GSSAPI بسيط وآمن. هذه واجهة قياسية للمصادقة (مثل JNDI لعمليات البحث عن الدليل) ، والتطبيق الافتراضي لـ SPNEGO على Windows هو Kerberos (مثل LDAP لـ JNDI). تستخدم مصطلحات Microsoft "مصادقة Windows المتكاملة" كمرادف لـ SPNEGO. في مصادقة Windows المتكاملة ، يمكن التفاوض على بروتوكولات Kerberos أو NTLM.

عندما يتلقى الخادم طلبًا من Internet Explorer (IE 6.1 أو أعلى) ، فقد يطلب أن يستخدم المتصفح بروتوكول SPNEGO للمصادقة. ينفذ هذا البروتوكول مصادقة Kerberos عبر HTTP ويسمح لـ Internet Explorer بتفويض السلطة المفوضة حتى يتمكن تطبيق الويب من تسجيل الدخول إلى خدمات Kerberized اللاحقة نيابة عن المستخدم.

عندما يريد خادم HTTP تشغيل SPNEGO ، فإنه يُرجع استجابة "401 غير مصرح بها" إلى طلب HTTP بعنوان "WWW-Authorization: Negotiate". يقوم Internet Explorer بعد ذلك بالاتصال بخدمة التذاكر (TGS) للحصول على تذكرة. يختار الاسم الخاص للمشارك في الخدمة لطلب تذكرة ، على سبيل المثال:

HTTP/webserver@<DOMAIN NAME> 

يتم بعد ذلك تغليف التذكرة التي تم إرجاعها برمز SPNEGO ، والذي يتم ترميزه وإرساله إلى الخادم باستخدام طلب HTTP. ينكشف الرمز ويصادق التذكرة.

فوائد Kerberos


يمكّن استخدام Kerberos المسؤولين من تعطيل مصادقة NTLM بمجرد أن يتمكن جميع عملاء الشبكة من مصادقة Kerberos. Kerberos أكثر مرونة وفعالية من NTLM وأكثر أمانًا.

تكوين SSO المستندة إلى Kerberos في بيئة خادم تطبيق Weblogic


مخطط التفاعل:



  1. عندما يطلب مستخدم مسجل (PC) موردًا من Oracle WebLogic Server (WLS) ، فإنه يرسل طلب HTTP GET الأصلي.
  2. يتطلب خادم Oracle WebLogic Server (WLS) الذي يقوم بتشغيل رمز SPNEGO المميز المصادقة ويصدر رفض الوصول 401 ، WWWAuthenticate: مفاوضة الاستجابة.
  3. يطلب عميل (متصفح على الكمبيوتر الشخصي) تذكرة جلسة من TGS / KDC (AD).
  4. يوفر TGS / KDC (AD) للعميل تذكرة Kerberos الضرورية (شريطة أن يكون العميل مفوضًا) ، ملفوفة في رمز SPNEGO المميز.
  5. يقوم العميل بإعادة إرسال طلب HTTP GET + رمز مفاوضة SPNEGO في رأس التفويض: مفاوضة base64 (الرمز المميز).
  6. التحقق من مصادقة ويب SPNEGO على خادم Weblogic يرى رأس HTTP مع رمز SPNEGO المميز. يتحقق SPNEGO من رمز SPNEGO ويحصل على معلومات المستخدم.
  7. بعد أن يتلقى Weblogic معلومات المستخدم ، فإنه يتحقق من صحة المستخدم في Microsoft Active Directory / KDC. عند اكتمال عملية المصادقة ، ينفذ Weblogic رمز Java المطابق (servlets و JSP و EJB وما إلى ذلك) ويتحقق من التفويض.
  8. يقبل رمز معالج Oracle WebLogic Server Token Handler الرمز المميز ويعالجه من خلال GSS API ، ويصادق على المستخدم ، ويستجيب بعنوان URL المطلوب.

الآن دعنا نتدرب


1. نقوم بتنفيذ الإعدادات على جانب الخادم من نطاق وحدة التحكم التي تم تكوين خدمات TGS / KDC عليها.

  • إنشاء مستخدم في Active Directory (يجب ألا تنتهي صلاحية كلمة المرور)
  • قم بتعيين SPN المناسب لاسم خادم WLS

تنفيذ التحقق الذي أنشأته SPN

 setspn –l HTTP_weblogic 

يجب إرجاع سجلين
إنشاء ملف Keytab

 ktpass -princ HTTP_weblogic@mycompany.com -pass PASSWORD -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:\krb5.keytab 

انسخ هذا الملف إلى خادم WLS

2. إعداد خادم WLS

  • تحتاج إلى إنشاء ملف krb5.ini في المجلد٪ windir٪: C: \ Windows. يحتوي هذا الملف على إعدادات التكوين للعملاء ، على سبيل المثال ، حيث يوجد KDC. سيبدو الملف كما يلي:

 [libdefaults] default_realm = <DOMAIN NAME> ticket_lifetime = 600 [realms] <DOMAIN NAME> = { kdc = <HOSTNAME OF AD/KDC> admin_server = <HOSTNAME OF AD/KDC> default_domain = <DOMAIN NAME> } [domain_realm] . <DOMAIN NAME>= <DOMAIN NAME> [appdefaults] autologin = true forward = true forwardable = true encrypt = true 

  • إنشاء ملف تكوين krb5Login.conf:

 com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; }; 

يرجى ملاحظة أنه يجب أن يكون اسم المجال كبيرًا . بالنسبة للإصدارات السابقة ، استخدم com.sun.security.jgss.initiate في التكوين السابق بدلاً من com.sun.security.jgss.krb5.initiate.

  • يجب وضع ملفات krb5Login.conf و krb5.keytab في جذر دليل مجال خادم WLS.

  • تحرير ملف setDomainEnv

أوجد مجموعة الخطوط JAVA_OPTIONS =٪ JAVA_OPTIONS٪ وأضفها في النهاية

 -Djava.security.auth.login.config=<  >\krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true 

  • في هذه الحالة ، لا نفكر في إعداد تفويض WLS في م ، ونعتقد أنه يعمل ، إذا كنت بحاجة إلى رسم هذا العنصر ، فاكتب في التعليقات.
  • تكوين SPNEGO في WLS
    للقيام بذلك ، انتقل إلى وحدة تحكم إدارة خادم WebLogic
    انتقل إلى القسم العوالم الأمنية> myrealm> الموفرون وانقر فوق الزر إضافة
    حدد نوع "موفر تأكيد هوية مفاوضة WebLogic"
    تحقق من تحديد كلا المعلمتين.



    نضغط على زر إعادة الترتيب والتحكم في الأسهم وضبط تسلسل أنواع التفويض. في المقام الأول يجب تثبيت WebLogic Negotiate Identity Assertion Provider في المركز الثاني الذي يقوم بإجراء مصادقة LDAP (تفويض المجال)


  • إعادة تشغيل الخادم

  • بعد ذلك ، تحتاج إلى إخبار التطبيق بطريقة ترخيص CLIENT-CERT ، ويتم تطبيق هذه التغييرات في ملف web.xml الخاص بالتطبيق

 <security-constraint> <display-name>Security Constraint for SSO </display-name> <web-resource-collection> <web-resource-name>My webapp</web-resource-name> <description>Group of Users</description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <description>Role description</description> <role-name>valid-users</role-name> </security-role> 

يجب تثبيت الدور مسبقًا في النظام. في حالتنا ، يتم استخدام الدور المضمن لـ ADF (المستخدمون الصالحون) ، بالإضافة إلى ذلك ، بناءً على مجموعات المجال ، يتم منح الأذونات.

  • تصحيح

لتحديد مشاكل التفويض ، يجب تمكين التصحيح. للقيام بذلك ، انتقل إلى القسم.

البيئة -> الخوادم ، حدد خادمنا -> تصحيح -> weblogic (توسيع) -> الأمان -> atn ، حدد المربع وتمكينه.



لتمكين وتعطيل التصحيح ، لا يلزم إعادة التشغيل.

  • نقوم بإعادة تشغيل الخادم لتطبيق تغييرات التكوين.
  • نشر التطبيق باستخدام طريقة تفويض معدلة (web.xml جديد)
  • لتعطيل هذا النوع من التفويض لوحدة التحكم الإدارية ، قم بإجراء التغييرات التالية٪ Ora_Home٪ \ wlserver \ server \ lib \ consoleapp \ webapp \ WEB-INF \ web.xml.

    قم بتغيير الخط

      <auth-method>CLIENT-CERT,FORM</auth-method>  <auth-method>FORM</auth-method> 

قم بتسجيل الدخول إلى جهاز المجال ، وانقر على رابط التطبيق وقم بتسجيل الدخول دون إدخال كلمة مرور. تجدر الإشارة إلى أن زر الخروج في التطبيق لن يعمل في هذا التكوين.

Source: https://habr.com/ru/post/ar414939/


All Articles