🦊 👨‍👩‍👧 ✡️ SSO على بنية الخدمات الصغيرة. نستخدم Keycloak. الجزء رقم 1 👨🏾‍🚒 🌎 💂🏼

في أي شركة كبيرة ، لا تعد X5 Retail Group استثناءً ، حيث يزداد عدد المشاريع التي تتطلب مصادقة المستخدم مع زيادة عدد المشاريع. بمرور الوقت ، يلزم الانتقال السلس للمستخدمين من تطبيق إلى آخر ، ثم هناك حاجة إلى استخدام خادم واحد أحادي الغناء (SSO). ولكن ماذا عن متى يتم بالفعل استخدام موفري الهوية مثل AD أو غيرهم الذين ليس لديهم سمات إضافية في مشاريع مختلفة. ستصل إلى الإنقاذ فئة من الأنظمة تسمى "وسطاء الهوية". والأكثر وظيفية هم ممثلوها ، مثل Keycloak ، وإدارة Gravitee Access ، وما إلى ذلك. في معظم الأحيان ، يمكن أن تكون سيناريوهات الاستخدام مختلفة: تفاعل الآلة ، مشاركة المستخدم ، إلخ. يجب أن يدعم الحل وظائف مرنة وقابلة للتطوير ،قادر على الجمع بين جميع المتطلبات في واحد ، ومثل هذا الحل في شركتنا هو وسيط مؤشر - Keycloak.

Keycloak هو منتج مفتوح المصدر للمصادقة والتحكم في الوصول مدعوم من RedHat. إنها أساس منتجات الشركة باستخدام SSO - RH-SSO.

مفاهيم أساسية

قبل أن تبدأ في التعامل مع القرارات والأساليب ، يجب عليك تحديد شروط وتسلسل العمليات:

التعريف هو عملية التعرف على الموضوع من خلال معرفه (بمعنى آخر ، هو تحديد اسم أو تسجيل دخول أو رقم).

المصادقة هي إجراء مصادقة (يتم التحقق من المستخدم باستخدام كلمة مرور ، ويتم التحقق من الرسالة عن طريق التوقيع الإلكتروني ، وما إلى ذلك)

الترخيص هو توفير الوصول إلى المورد (على سبيل المثال ، البريد الإلكتروني).

وسيط هوية Keycloak

Keycloak هو حل مفتوح المصدر لإدارة الهوية والوصول مصمم للاستخدام في الدوائر المتكاملة حيث يمكن استخدام أنماط بنية الخدمات المصغرة.

تقدم Keycloak ميزات مثل الدخول الموحّد (SSO) ، وتعريف الوسيط وتسجيل الدخول الاجتماعي ، واتحاد المستخدم ، ومحولات العملاء ، ووحدة تحكم المشرف ، ووحدة تحكم إدارة الحساب.

الوظائف الأساسية المدعومة في Keycloak:

الدخول الموحد وتسجيل الخروج الفردي للتطبيقات المستندة إلى المستعرض.
دعم OpenID / OAuth 2.0 / SAML.
هوية السمسرة - المصادقة باستخدام OpenID Connect أو موفري هوية SAML.
تسجيل الدخول الاجتماعي - دعم Google و GitHub و Facebook و Twitter لتحديد المستخدم.
User Federation – LDAP Active Directory .
Kerberos bridge – Kerberos .
Admin Console — Web.
Account Management Console – .
.
2FA Authentication – TOTP/HOTP Google Authenticator FreeOTP.
Login Flows – , .
Session Management – .
Token Mappers – , .
realm, application .
CORS Support – CORS.
Service Provider Interfaces (SPI) – SPI, : , , .
JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
, OpenID Connect Relying Party library SAML 2.0 Service Provider Library.
plugins.

بالنسبة لعمليات CI / CD ، وكذلك أتمتة عمليات الإدارة في Keycloak ، يمكن استخدام REST API / JAVA API. الوثائق متاحة في شكل إلكتروني:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
JAVA API https://www.keycloak.org/docs-api/8.0/javadocs /index.html

موفرو هوية المؤسسة (داخل المؤسسة)

القدرة على مصادقة المستخدمين من خلال خدمات اتحاد المستخدم.

يمكن أيضًا استخدام مصادقة المرور - إذا قام المستخدمون بالمصادقة في محطات العمل مع Kerberos (LDAP أو AD) ، فيمكن مصادقتهم تلقائيًا على Keycloak دون الحاجة إلى تقديم اسم المستخدم وكلمة المرور مرة أخرى.

من أجل المصادقة والتفويض الإضافي للمستخدمين ، من الممكن استخدام نظام إدارة قواعد البيانات العلائقية ، وهو الأكثر قابلية للتطبيق في بيئات التطوير ، لأنه لا ينطوي على إعدادات وعمليات تكامل طويلة المدى في المراحل الأولى من المشاريع. بشكل افتراضي ، يستخدم Keycloak نظام DBMS مضمن لتخزين الإعدادات وبيانات المستخدم.

قائمة DBMSs المدعومة واسعة النطاق وتشمل: MS SQL و Oracle و PostgreSQL و MariaDB و Oracle وغيرها. الأكثر اختبارًا في الوقت الحالي هي مجموعة Oracle 12C Release1 RAC و Galera 3.12 لـ MariaDB 10.1.19.

موفري الهوية - تسجيل الدخول الاجتماعي

من الممكن استخدام تسجيل دخول من الشبكات الاجتماعية. لتنشيط القدرة على مصادقة المستخدمين ، يتم استخدام وحدة تحكم المشرف Keycloack. التغييرات في رمز التطبيق غير مطلوبة وهذه الوظيفة متاحة "خارج الصندوق" ويمكن تفعيلها في أي مرحلة من مراحل المشروع.

لمصادقة المستخدمين ، من الممكن استخدام موفري هوية OpenID / SAML.

سيناريوهات التخويل النموذجية باستخدام OAuth2 في Keycloak

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

التدفق الضمني - يستخدم بواسطة تطبيقات الهاتف المحمول أو الويب (التطبيقات التي تعمل على جهاز المستخدم).

يتم استخدام نوع ضمني من إذن التفويض بواسطة تطبيقات الهاتف المحمول والويب حيث لا يمكن ضمان خصوصية العميل. يستخدم نوع الإذن الضمني أيضًا إعادة توجيه وكيل المستخدم ، ويتم تمرير رمز الوصول إلى وكيل المستخدم لمزيد من الاستخدام في التطبيق. يؤدي ذلك إلى إتاحة الرمز المميز للمستخدم والتطبيقات الأخرى على جهاز المستخدم. باستخدام هذا النوع من إذن التفويض ، لا تتم مصادقة التطبيق ، وتعتمد العملية نفسها على عنوان URL لإعادة التوجيه (المسجل سابقًا في الخدمة).

التدفق الضمني لا يدعم الرموز المميزة للتحديث.
تدفق منح بيانات اعتماد العميل - يُستخدم عند وصول التطبيق إلى واجهة برمجة التطبيقات. يُستخدم هذا النوع من إذن التفويض عادةً للتفاعلات من خادم إلى خادم التي يجب تشغيلها في الخلفية دون تفاعل فوري من المستخدم. يسمح تدفق بيانات اعتماد العميل لخدمة الويب (العميل السري) باستخدام بيانات الاعتماد الخاصة به بدلاً من انتحال صفة المستخدم للمصادقة عند الاتصال بخدمة ويب أخرى. للحصول على مستوى أعلى من الأمان ، من الممكن لخدمة الاتصال استخدام شهادة (بدلاً من سر مشترك) كأوراق اعتماد.

يتم وصف مواصفات OAuth2 في
RFC-6749
RFC-8252
RFC-6819

رمز JWT ومزاياه

JWT (JSON Web Token) هو معيار مفتوح ( https://tools.ietf.org/html/rfc7519 ) يحدد طريقة مدمجة ومستقلة لنقل المعلومات بشكل آمن بين الأطراف ككائن JSON.

وفقًا للمعيار ، يتكون الرمز المميز من ثلاثة أجزاء بتنسيق 64-base ، مفصولة بنقاط. يُسمى الجزء الأول الرأس ، الذي يحتوي على نوع الرمز المميز واسم خوارزمية التجزئة للحصول على توقيع رقمي. يقوم الجزء الثاني بتخزين المعلومات الأساسية (المستخدم ، السمات ، إلخ). الجزء الثالث هو توقيع رقمي.

<رأس مشفر>. <حمولة مشفرة>. <توقيع>
لا تقم بحفظ رمز مميز في قاعدة البيانات الخاصة بك. نظرًا لأن رمزًا صالحًا يعادل كلمة مرور ، فإن تخزين رمز مميز يشبه تخزين كلمة مرور بنص واضح.
رمز الوصول هو رمز مميز يمنح مالكه حق الوصول إلى الموارد المحمية للخادم. عادة ما يكون لها عمر قصير ويمكن أن تحمل معلومات إضافية ، مثل عنوان IP للطرف الذي يطلب هذا الرمز المميز.

الرمز المميز للتحديث هو رمز مميز يسمح للعملاء بطلب رموز وصول جديدة بعد انتهاء مدة حياتهم. عادةً ما يتم إصدار هذه الرموز المميزة لفترة طويلة.

المزايا الرئيسية للتطبيق في بنية الخدمات الصغيرة:

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

JWT Token - التركيب

الرأس - بشكل افتراضي ، يحتوي الرأس على نوع الرمز المميز والخوارزمية المستخدمة للتشفير فقط.

يتم تخزين نوع الرمز المميز في مفتاح "الطباع". يتم تجاهل المفتاح "typ" في JWT. إذا كان مفتاح الكتابة موجودًا ، فيجب أن تكون قيمته JWT للإشارة إلى أن هذا الكائن هو رمز JSON Web Token.

يحدد مفتاح alg الثاني الخوارزمية المستخدمة لتشفير الرمز المميز. بشكل افتراضي ، يجب تعيينه على HS256. تم ترميز الرأس في base64.

{"alg": "HS256"، "typ": "JWT"}
الحمولة (المحتوى) - تقوم الحمولة بتخزين أي معلومات تحتاج إلى التحقق منها. يُعرف كل مفتاح في الحمولة باسم "كشف". على سبيل المثال ، لا يمكن إدخال التطبيق إلا من خلال دعوة (عرض ترويجي مغلق). عندما نريد دعوة شخص للمشاركة ، نرسل له رسالة دعوة. من المهم التحقق من أن عنوان البريد الإلكتروني ينتمي إلى الشخص الذي يقبل الدعوة ، لذلك سنقوم بتضمين هذا العنوان في الحمولة ، لذلك سنقوم بحفظه في مفتاح "البريد الإلكتروني"

{"البريد الإلكتروني": "example@x5.ru"}
يمكن أن تكون المفاتيح في الحمولة عشوائية. ومع ذلك ، هناك عدد قليل منها محجوز:

iss (Issuer) - يحدد التطبيق الذي يتم إرسال الرمز المميز منه.
sub (الموضوع) - يحدد موضوع الرمز المميز.
aud (Audience) – URI, . JWT , — .
exp (Expiration Time) — , . JWT , . Exp unix .
nbf (Not Before) — unix , , .
iat (Issued At) — , JWT. iat unix .
Jti (JWT ID) — , c .

من المهم أن نفهم أن الحمولة لا تنتقل في شكل مشفر (على الرغم من أنه يمكن تضمين الرموز المميزة ومن ثم يمكن نقل البيانات المشفرة). لذلك ، من المستحيل تخزين أي معلومات سرية فيه. مثل الرأس ، يتم ترميز الحمولة في base64.
التوقيع - عندما يكون لدينا رأس وحمولة ، يمكننا حساب التوقيع.

ترميز Base64: يتم أخذ الرأس والحمولة ، ويتم دمجهما في خط من خلال نقطة. ثم يتم إرسال هذا الخط والمفتاح السري إلى إدخال خوارزمية التشفير المحددة في الرأس (المفتاح "alg"). يمكن أن يكون المفتاح أي سلسلة. سيكون من الأفضل استخدام سلاسل أطول ، حيث سيستغرق الأمر وقتًا أطول للمطابقة.

{"alg": "RSA1_5"، "payload": "A128CBC-HS256"}

العمارة العنقودية تجاوز الفشل Keycloak

عند استخدام مجموعة واحدة لجميع المشاريع ، هناك متطلبات متزايدة لحل لـ SSO. عندما يكون عدد المشاريع صغيرًا ، لا تكون هذه المتطلبات ملحوظة جدًا لجميع المشاريع ، ولكن مع زيادة عدد المستخدمين والتكاملات ، تزداد متطلبات إمكانية الوصول والإنتاجية.

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

للعمل في المجموعات النشطة / النشطة والمجموعات النشطة / السلبية ، يلزم التأكد من تناسق البيانات في قاعدة بيانات علائقية - يجب نسخ كلا عقدتي قاعدة البيانات بشكل متزامن بين مراكز البيانات الموزعة جغرافيًا المختلفة.

أبسط مثال على التثبيت الآمن من الفشل.

ما فوائد استخدام مجموعة واحدة:

التوفر والأداء العالي.
دعم أوضاع التشغيل: نشط / نشط ، نشط / سلبي.
القدرة على القياس ديناميكيًا - عند استخدام المحاكاة الافتراضية للحاويات.
إمكانية الإدارة والرصد المركزيين.
نهج موحد لتحديد / توثيق / تفويض المستخدمين في المشاريع.
تفاعل أكثر شفافية بين المشاريع المختلفة دون مشاركة المستخدم.
القدرة على إعادة استخدام الرمز المميز JWT في مشاريع مختلفة.
نقطة ثقة واحدة.
إطلاق أسرع للمشروعات باستخدام المحاكاة الافتراضية للخدمات الصغيرة / الحاويات (لا حاجة إلى رفع مكونات إضافية وتكوينها).
ربما اكتساب الدعم التجاري من البائع.

أشياء يجب مراعاتها عند التخطيط لكتلة

DBMS

تستخدم Keycloak نظام إدارة DBMS للحفظ: العوالم والعملاء والمستخدمين وما إلى ذلك.
يتم دعم مجموعة كبيرة من DBMSs: MS SQL و Oracle و MySQL و PostgreSQL. يأتي Keycloak مع قاعدة بيانات علائقية خاصة به. يوصى باستخدامه في البيئات غير المحملة مثل بيئات التطوير.

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

ذاكرة التخزين المؤقت الموزعة (Infinspan)

لكي تعمل الكتلة بشكل صحيح ، يلزم إجراء مزامنة إضافية لأنواع ذاكرة التخزين المؤقت التالية باستخدام شبكة بيانات JBoss:

جلسات المصادقة - تُستخدم لحفظ البيانات أثناء مصادقة مستخدم معين. تتضمن الطلبات من ذاكرة التخزين المؤقت هذه عادةً المتصفح وخادم Keycloak فقط ، وليس التطبيق.

الرموز المميزة للإجراء - تُستخدم في السيناريوهات عندما يحتاج المستخدم إلى تأكيد الإجراء بشكل غير متزامن (عبر البريد الإلكتروني). على سبيل المثال ، أثناء دفق كلمة المرور المنسية ، يتم استخدام ذاكرة التخزين المؤقت actionTokens Infinispan لتتبع البيانات الوصفية حول علامات الإجراءات ذات الصلة التي تم استخدامها بالفعل ، لذلك لا يمكن إعادة استخدامها.

التخزين المؤقت وإبطال البيانات المستمرة - يستخدم لتخزين البيانات المستمرة مؤقتًا لتجنب استعلامات قاعدة البيانات غير الضرورية. عندما يقوم خادم Keycloak بتحديث البيانات ، يجب أن تكون جميع خوادم Keycloak الأخرى في جميع مراكز البيانات على علم بذلك.

العمل - يُستخدم فقط لإرسال رسائل إلغاء الصلاحية بين عقد الكتلة ومراكز البيانات.

جلسات المستخدم - تُستخدم لحفظ البيانات حول جلسات المستخدم الصالحة لجلسة المتصفح الخاصة بالمستخدم. يجب أن تتعامل ذاكرة التخزين المؤقت مع طلبات HTTP من المستخدم والتطبيق.

حماية القوة الغاشمة - تستخدم لتتبع بيانات تسجيل الدخول الفاشلة.

توزيع الحمل

موازن التحميل هو نقطة دخول واحدة في keycloak ويجب أن يدعم الجلسات اللزجة.

خادم التطبيق

يتم استخدامها للتحكم في تفاعل المكونات فيما بينها ويمكن جعلها ظاهرية أو في حاوية باستخدام أدوات الأتمتة الحالية وتوسيع أدوات أتمتة البنية التحتية ديناميكيًا. سيناريوهات النشر الأكثر شيوعًا في OpenShift و Kubernetes و Rancher.

حول هذا ، الجزء الأول - النظري - قد انتهى. في سلسلة المقالات التالية ، ستتم مناقشة أمثلة للتكامل مع مختلف موفري الهوية وأمثلة التكوين.

SSO على بنية الخدمات الصغيرة. نستخدم Keycloak. الجزء رقم 1