في أي شركة كبيرة ، فإن X5 Retail Group ليست استثناءً ، لأنها تتطور ، يزداد عدد المشاريع التي تتطلب إذن المستخدم. بمرور الوقت ، يلزم الانتقال السلس للمستخدمين من تطبيق إلى آخر ، ومن ثم هناك حاجة لاستخدام خادم فردي واحد (SSO). ولكن ماذا عن الوقت الذي يتم فيه استخدام موفري الهوية مثل AD أو الآخرين الذين ليس لديهم سمات إضافية بالفعل في مشاريع مختلفة. ستأتي فئة من الأنظمة تسمى "وسطاء تحديد الهوية" للإنقاذ. الأكثر فاعلية هم ممثلوها ، مثل Keycloak و Gravitee Access management ، إلخ. في أغلب الأحيان ، يمكن أن تكون حالات الاستخدام مختلفة: تفاعل الآلة ، مشاركة المستخدم ، إلخ. يجب أن يدعم الحل وظائف مرنة وقابلة للتطوير يمكن أن تجمع بين جميع المتطلبات في واحد ، ومثل هذه الحلول لدى شركتنا الآن وسيط للإشارة - Keycloak.
Keycloak هو هوية مفتوحة المصدر ومنتج للتحكم في الوصول تحتفظ به RedHat. إنه أساس منتجات الشركة التي تستخدم SSO - RH-SSO.
المفاهيم الأساسية
قبل أن تبدأ في التعامل مع الحلول والأساليب ، يجب أن تقرر من حيث وتسلسل العمليات:
تحديد هو إجراء للتعرف على موضوع من خلال معرفه (بمعنى آخر ، هذا هو تعريف الاسم أو تسجيل الدخول أو الرقم).
المصادقة - هذا إجراء مصادقة (يتم التحقق من المستخدم بكلمة مرور ، ويتم التحقق من الحرف بتوقيع إلكتروني ، وما إلى ذلك)
ترخيص - هذا هو توفير الوصول إلى مورد (على سبيل المثال ، إلى البريد الإلكتروني).
وسيط الهوية Keycloak
كيلوك هو حل إدارة الوصول والهوية مفتوح المصدر مصمم للاستخدام في IS حيث يمكن استخدام أنماط بنية الخدمات المصغرة.
يوفر Keycloak ميزات مثل تسجيل الدخول الأحادي (SSO) والهوية الوسيطة وتسجيل الدخول الاجتماعي واتحاد المستخدم ومحولات العميل ووحدة تحكم المشرف ووحدة التحكم في إدارة الحساب.
الوظائف الأساسية التي يدعمها Keycloak:
- تسجيل الدخول الأحادي وتسجيل الخروج الأحادي لتطبيقات المتصفح.
- دعم OpenID / OAuth 2.0 / SAML.
- سمسرة الهوية - المصادقة باستخدام موفري هوية OpenID Connect أو SAML الخارجيين.
- تسجيل الدخول الاجتماعي - دعم Google و GitHub و Facebook و Twitter لتحديد هوية المستخدم.
- اتحاد المستخدم - مزامنة المستخدمين من خوادم LDAP و Active Directory وموفري الهوية الآخرين.
- جسر Kerberos - استخدام خادم Kerberos للمصادقة التلقائية على المستخدم.
- وحدة تحكم المشرف - لإدارة موحدة للإعدادات وخيارات الحلول عبر الويب.
- وحدة تحكم إدارة الحساب - للإدارة الذاتية لملف تعريف المستخدم.
- تخصيص الحل بناءً على الهوية المؤسسية للشركة.
- مصادقة 2FA - دعم TOTP / HOTP باستخدام Google Authenticator أو FreeOTP.
- تدفقات تسجيل الدخول - يمكن التسجيل الذاتي للمستخدم ، واستعادة كلمة المرور وإعادة تعيينها ، وغير ذلك.
- إدارة الجلسة - يمكن للمسؤولين إدارة جلسات المستخدم من نقطة واحدة.
- مصممي الرموز المميزة - سمات المستخدم الملزمة والأدوار والسمات الأخرى المطلوبة للرموز المميزة.
- إدارة سياسة مرنة عبر المجال والتطبيق والمستخدمين.
- دعم CORS - تحتوي محولات العميل على دعم CORS مدمج.
- واجهات مزود الخدمة (SPI) - عدد كبير من SPIs التي تسمح لك بتخصيص جوانب مختلفة من الخادم: تدفقات المصادقة وموفرو الهوية وتخطيط البروتوكول والمزيد.
- محولات العميل لتطبيقات JavaScript ، WildFly ، JBoss EAP ، Fuse ، Tomcat ، Jetty ، Spring.
- دعم للعمل مع التطبيقات المختلفة التي تدعم مكتبة OpenID Connect Relying Party أو مكتبة مزود خدمة SAML 2.0.
- قابل للتوسيع باستخدام الإضافات.
بالنسبة لعمليات CI / CD ، بالإضافة إلى أتمتة عمليات الإدارة في Keycloak ، يمكن استخدام REST API / JAVA API. التوثيق متاح إلكترونيًا:
REST API
جافا API
موفرو هوية المؤسسة (في مكان العمل)
القدرة على مصادقة المستخدمين من خلال خدمات اتحاد المستخدم.
يمكن أيضًا استخدام المصادقة التمريرية - إذا قام المستخدمون بالمصادقة على محطات العمل مع Kerberos (LDAP أو AD) ، فيمكن مصادقتهم تلقائيًا إلى Keycloak دون الحاجة إلى إدخال اسم المستخدم وكلمة المرور مرة أخرى.
للمصادقة والمزيد من التفويضات للمستخدمين ، من الممكن استخدام DBMS العلائقية ، وهو الأكثر قابلية للتطبيق لبيئات التطوير ، لأنه لا يتضمن إعدادات طويلة وتكاملات في المراحل الأولى من المشاريع. بشكل افتراضي ، يستخدم Keycloak نظام DBMS مدمج لتخزين الإعدادات وبيانات المستخدم.
قائمة نظم إدارة قواعد البيانات المدعومة شاملة وتشمل: MS SQL و Oracle و PostgreSQL و MariaDB و Oracle وغيرها. الأكثر اختبارًا حتى الآن هي مجموعة Oracle 12C Release1 RAC و Galera 3.12 لـ MariaDB 10.1.19.
موفرو الهوية - تسجيل الدخول الاجتماعي
من الممكن استخدام تسجيل الدخول من الشبكات الاجتماعية. لتنشيط القدرة على مصادقة المستخدمين ، استخدم وحدة تحكم المشرف Keycloack. التغييرات في رمز التطبيق غير مطلوبة وهذه الوظيفة متاحة خارج الصندوق ويمكن تفعيلها في أي مرحلة من مراحل المشروع.
من الممكن استخدام موفري هوية OpenID / SAML لمصادقة المستخدم.
سيناريوهات المصادقة النموذجية باستخدام OAuth2 في Keycloak
تدفق رمز التفويض - تستخدم مع التطبيقات من جانب الخادم. أحد أكثر أنواع أذونات التفويض شيوعًا لأنه مناسب تمامًا لتطبيقات الخادم حيث لا يتوفر كود مصدر التطبيق وبيانات العميل للأجانب. تعتمد العملية في هذه الحالة على إعادة التوجيه. يجب أن يكون التطبيق قادرًا على التفاعل مع وكيل مستخدم (وكيل مستخدم) ، مثل متصفح الويب - لتلقي رموز تفويض واجهة برمجة التطبيقات التي تمت إعادة توجيهها من خلال وكيل المستخدم.
التدفق الضمني - مستخدمة بواسطة تطبيقات الجوال أو الويب (التطبيقات التي تعمل على جهاز المستخدم).
يتم استخدام نوع إذن التفويض الضمني بواسطة تطبيقات الجوال والويب حيث لا يمكن ضمان سرية العميل. يستخدم نوع الإذن الضمني أيضًا إعادة توجيه وكيل المستخدم ، حيث يتم تمرير رمز الوصول إلى وكيل المستخدم لمزيد من الاستخدام في التطبيق. هذا يجعل الرمز المميز متاحًا للمستخدم والتطبيقات الأخرى على جهاز المستخدم. لا يقوم هذا النوع من إذن التفويض بمصادقة هوية التطبيق ، وتعتمد العملية نفسها على عنوان URL لإعادة التوجيه (تم تسجيله مسبقًا في الخدمة).
لا يدعم التدفق الضمني الرموز المميزة لتحديث رمز الوصول.
تدفق منح أوراق اعتماد العميل - تُستخدم عندما يصل التطبيق إلى واجهة برمجة التطبيقات. يتم استخدام هذا النوع من إذن التفويض عادةً للتفاعلات من خادم إلى خادم والتي يجب إجراؤها في الخلفية دون تدخل فوري من المستخدم. يسمح تدفق منح بيانات اعتماد العميل لخدمة الويب (عميل سري) باستخدام بيانات الاعتماد الخاصة به بدلاً من انتحال شخصية المستخدم للمصادقة عند الاتصال بخدمة ويب أخرى. للحصول على مستوى أعلى من الأمان ، يمكن لخدمة الاتصال استخدام شهادة (بدلاً من السر المشترك) كأوراق اعتماد.
تم وصف مواصفات OAuth2 في
رمز JWT وفوائده
JWT (JSON Web Token) هو معيار مفتوح () التي تحدد طريقة مدمجة وقائمة بذاتها لنقل المعلومات بشكل آمن بين الأطراف ككائن JSON.
وفقًا للمعيار ، يتكون الرمز المميز من ثلاثة أجزاء بتنسيق base-64 ، مفصولة بنقاط. يُطلق على الجزء الأول اسم الرأس ، والذي يحتوي على نوع الرمز المميز واسم خوارزمية التجزئة للحصول على توقيع رقمي. الجزء الثاني يخزن المعلومات الأساسية (المستخدم ، السمات ، إلخ). الجزء الثالث هو التوقيع الرقمي.
. .
لا تقم أبدًا بتخزين رمز مميز في قاعدة البيانات الخاصة بك. نظرًا لأن الرمز المميز يعادل كلمة المرور ، فإن تخزين الرمز المميز يشبه تخزين كلمة المرور في نص واضح.
رمز وصول هو رمز يمنح مالكه حق الوصول إلى موارد الخادم الآمنة. عادةً ما يكون له عمر قصير وقد يحمل معلومات إضافية مثل عنوان IP للطرف الذي يطلب الرمز المميز.
تحديث الرمز هو رمز يسمح للعملاء بطلب رموز وصول جديدة بعد انتهاء عمرها الافتراضي. عادة ما يتم إصدار هذه الرموز لفترة طويلة من الزمن.
المزايا الرئيسية للاستخدام في بنية الخدمات المصغرة:
- القدرة على الوصول إلى التطبيقات والخدمات المختلفة من خلال المصادقة لمرة واحدة.
- في حالة عدم وجود عدد من السمات المطلوبة في ملف تعريف المستخدم ، فمن الممكن إثراء البيانات التي يمكن إضافتها إلى الحمولة ، بما في ذلك البيانات الآلية والمتحركة.
- ليست هناك حاجة لتخزين المعلومات حول الجلسات النشطة ، يحتاج تطبيق الخادم فقط إلى التحقق من التوقيع.
- مزيد من المرونة في التحكم في الوصول من خلال سمات إضافية في الحمولة.
- يزيد استخدام التوقيع المميز للرأس والحمولة من أمان الحل ككل.
رمز JWT - التكوين
لقب - بشكل افتراضي ، يحتوي العنوان فقط على نوع الرمز المميز والخوارزمية المستخدمة للتشفير.
يتم تخزين نوع الرمز المميز في مفتاح "الكتابة". يتم تجاهل مفتاح "النوع" في JWT. إذا كان مفتاح "الكتابة" موجودًا ، فيجب أن تكون قيمته هي JWT للإشارة إلى أن هذا الكائن هو رمز ويب JSON.
يحدد المفتاح الثاني "alg" الخوارزمية المستخدمة لتشفير الرمز المميز. يجب تعيينه على HS256 افتراضيًا. تم ترميز العنوان في base64.
{"alg": "HS256"، "type": "JWT"}
الحمولة (المحتوى) - تخزن الحمولة أي معلومات تحتاج إلى التحقق منها. يُعرف كل مفتاح في الحمولة باسم "مطالبة". على سبيل المثال ، يمكنك إدخال التطبيق فقط عن طريق الدعوة (الترويجي المغلق). عندما نريد دعوة شخص ما للمشاركة ، نرسل له خطاب دعوة. من المهم التحقق من أن عنوان البريد الإلكتروني يخص الشخص الذي يقبل الدعوة ، لذلك سنقوم بتضمين هذا العنوان في الحمولة ، لذلك نقوم بتخزينه في مفتاح "البريد الإلكتروني"
{ "بريد إلكتروني": "[البريد الإلكتروني محمي]" }
يمكن أن تكون المفاتيح الموجودة في الحمولة عشوائية. ومع ذلك ، هناك عدد قليل محجوز:
- iss (المُصدر) - يحدد التطبيق الذي يتم إرسال الرمز منه.
- sub (الموضوع) - يحدد موضوع الرمز المميز.
- audience (الجمهور) عبارة عن مجموعة من السلاسل أو URIs الحساسة لحالة الأحرف وهي قائمة بمستلمي هذا الرمز المميز. عندما يتلقى الجانب المستقبل JWT بالمفتاح المحدد ، يجب عليه التحقق من وجوده في المستلمين - وإلا تجاهل الرمز المميز.
- exp (وقت انتهاء الصلاحية) - يشير إلى وقت انتهاء صلاحية الرمز المميز. يتطلب معيار JWT من جميع تطبيقاته رفض الرموز المميزة منتهية الصلاحية. يجب أن يكون مفتاح exp طابعًا زمنيًا بتنسيق unix.
- nbf (ليس قبل) هو وقت بتنسيق unix يحدد اللحظة التي يصبح فيها الرمز المميز صالحًا.
- iat (صادر في) - يمثل هذا المفتاح وقت إصدار الرمز المميز ويمكن استخدامه لتحديد عمر JWT. يجب أن يكون مفتاح iat طابعًا زمنيًا بتنسيق unix.
- Jti (JWT ID) - سلسلة تحدد المعرف الفريد لهذا الرمز المميز ، حساس لحالة الأحرف.
من المهم أن نفهم أن الحمولة لا يتم إرسالها في شكل مشفر (على الرغم من إمكانية دمج الرموز المميزة ومن الممكن بعد ذلك نقل البيانات المشفرة). لذلك ، لا يمكنه تخزين أي معلومات سرية. مثل الرأس ، تكون الحمولة بترميز base64.
توقيع - عندما يكون لدينا عنوان وحمولة ، يمكننا حساب التوقيع.
ترميز Base64: يتم أخذ الرأس والحمولة ، ويتم دمجهما في سلسلة من خلال نقطة. ثم يتم إدخال هذه السلسلة والمفتاح السري في خوارزمية التشفير المحددة في الرأس (مفتاح "alg"). يمكن أن يكون المفتاح أي سلسلة. يفضل استخدام السلاسل الأطول حيث سيستغرق التقاطها وقتًا أطول.
{"alg": "RSA1_5"، "الحمولة": "A128CBC-HS256"}
بناء هيكل مجموعة Keycloak Failover Cluster
عند استخدام مجموعة واحدة لجميع المشاريع ، هناك متطلبات متزايدة لحل الدخول الموحّد (SSO). عندما يكون عدد المشاريع صغيرًا ، لا تكون هذه المتطلبات ملحوظة جدًا لجميع المشاريع ، ومع ذلك ، مع زيادة عدد المستخدمين وعمليات الدمج ، تزداد متطلبات التوافر والأداء.
تؤدي زيادة مخاطر فشل SSO الفردي إلى زيادة متطلبات بنية الحل والأساليب المستخدمة للمكونات الزائدة عن الحاجة ويؤدي إلى اتفاقية SLA محكمة للغاية. في هذا الصدد ، في كثير من الأحيان أثناء التطوير أو في المراحل الأولى من تنفيذ الحلول ، يكون للمشاريع بنية تحتية خاصة بها لا تتسامح مع الأخطاء. مع تقدم التنمية ، من الضروري توفير فرص للتطوير والتوسع. من الأكثر مرونة إنشاء مجموعة تجاوز الفشل باستخدام المحاكاة الافتراضية للحاويات أو النهج المختلط.
للعمل في أوضاع الكتلة النشطة / النشطة والنشطة / الخاملة ، يلزم ضمان اتساق البيانات في قاعدة البيانات العلائقية - يجب تكرار كلا عقدتي قاعدة البيانات بشكل متزامن بين مختلف مراكز البيانات الموزعة جغرافيًا.
أبسط مثال على التثبيت المتسامح.
ما هي فوائد استخدام الكتلة الواحدة:
- التوافر والأداء العالي.
- دعم أوضاع التشغيل: نشط / نشط ، نشط / سلبي.
- القدرة على التوسع ديناميكيًا - عند استخدام المحاكاة الافتراضية للحاويات.
- إمكانية الإدارة والمراقبة المركزية.
- نهج موحد لتحديد / المصادقة / ترخيص المستخدمين في المشاريع.
- تفاعل أكثر شفافية بين المشاريع المختلفة دون مشاركة المستخدم.
- القدرة على إعادة استخدام رمز JWT في مشاريع مختلفة.
- نقطة ثقة واحدة.
- إطلاق أسرع للمشاريع باستخدام الخدمات المصغرة / المحاكاة الافتراضية للحاويات (لا حاجة لرفع وتهيئة المكونات الإضافية).
- من الممكن شراء الدعم التجاري من البائع.
ما الذي تبحث عنه عند التخطيط للكتلة
نظام إدارة قواعد البيانات
يستخدم Keycloak نظام إدارة قاعدة البيانات لتخزين: العوالم ، العملاء ، المستخدمين ، إلخ.
يتم دعم مجموعة واسعة من نظم إدارة قواعد البيانات: MS SQL و Oracle و MySQL و PostgreSQL. Keycloak يأتي مع قاعدة البيانات العلائقية المدمجة الخاصة به. يوصى باستخدامه مع البيئات غير المحملة - مثل بيئات التطوير.
للعمل في أوضاع الكتلة النشطة / النشطة والنشطة / الخاملة ، يلزم تناسق البيانات في قاعدة البيانات العلائقية ، ويتم نسخ عقدتي كتلة قاعدة البيانات بشكل متزامن بين مراكز البيانات.
ذاكرة التخزين المؤقت الموزعة (Infinspan)
لكي تعمل الكتلة بشكل صحيح ، يلزم إجراء مزامنة إضافية للأنواع التالية من ذاكرات التخزين المؤقت باستخدام شبكة بيانات JBoss:
جلسات المصادقة - تُستخدم لحفظ البيانات عند مصادقة مستخدم معين. عادةً ما تتضمن الطلبات من ذاكرة التخزين المؤقت هذه المتصفح وخادم Keycloak فقط ، وليس التطبيق.
تُستخدم الرموز المميزة للإجراء في السيناريوهات التي يحتاج فيها المستخدم إلى تأكيد إجراء بشكل غير متزامن (عبر البريد الإلكتروني). على سبيل المثال ، أثناء تدفق نسيان كلمة المرور ، يتم استخدام ذاكرة التخزين المؤقت actionTokens Infinispan لتتبع البيانات الوصفية المتعلقة برموز الإجراءات المرتبطة التي تم استخدامها بالفعل ، لذلك لا يمكن إعادة استخدامها.
التخزين المؤقت وإلغاء صلاحية البيانات الدائمة - تُستخدم لتخزين البيانات الدائمة مؤقتًا لتجنب الاستعلامات غير الضرورية في قاعدة البيانات. عندما يقوم أي خادم Keycloak بتحديث البيانات ، فإن جميع خوادم Keycloak الأخرى في جميع مراكز البيانات بحاجة إلى معرفة ذلك.
العمل - يُستخدم فقط لإرسال رسائل غير صالحة بين عقد المجموعة ومراكز البيانات.
جلسات المستخدم - تُستخدم لتخزين البيانات حول جلسات المستخدم الصالحة طوال مدة جلسة متصفح المستخدم. يجب أن تعالج ذاكرة التخزين المؤقت طلبات HTTP من المستخدم والتطبيق.
الحماية من القوة الغاشمة - تُستخدم لتتبع البيانات حول عمليات تسجيل الدخول الفاشلة.
توزيع الحمل
موازن التحميل هو نقطة الدخول الفردية إلى keycloak ويجب أن يدعم الجلسات اللاصقة.
خوادم التطبيق
يتم استخدامها للتحكم في تفاعل المكونات مع بعضها البعض ويمكن جعلها افتراضية أو وضعها في حاويات باستخدام أدوات الأتمتة الحالية والتحجيم الديناميكي لأدوات أتمتة البنية التحتية. سيناريوهات النشر الأكثر شيوعًا في OpenShift و Kubernates و Rancher.
هذا يختتم الجزء الأول - الجزء النظري. في السلسلة التالية من المقالات ، سيتم تحليل أمثلة على عمليات التكامل مع موفري الهوية المختلفين وأمثلة على الإعدادات.
المصدر: www.habr.com