قبل بضعة أشهر ، كنت أستخدم خادم OpenID Connect لإدارة الوصول لمئات من تطبيقاتنا الداخلية. من مشاريعنا الخاصة ، المريحة على نطاق أصغر ، انتقلنا إلى معيار مقبول بشكل عام. يعمل الوصول من خلال الخدمة المركزية على تبسيط العمليات الرتيبة إلى حد كبير ، ويقلل من تكلفة تنفيذ التراخيص ، ويسمح لك بالعثور على العديد من الحلول الجاهزة وليس إجهاد عقلك عند تطوير حلول جديدة. في هذا المقال سوف أتحدث عن هذا الانتقال والمطبات التي تمكنا من سدها.
منذ زمن بعيد ... كيف بدأ كل شيء
قبل بضع سنوات ، عندما كان هناك عدد كبير جدًا من التطبيقات الداخلية للتحكم اليدوي ، كتبنا تطبيقًا للتحكم في الوصول داخل الشركة. لقد كان تطبيقًا بسيطًا من Rails كان متصلاً بقاعدة بيانات تحتوي على معلومات حول الموظفين ، حيث تم تكوين الوصول إلى وظائف مختلفة. في الوقت نفسه ، قمنا برفع أول SSO ، والذي كان يعتمد على التحقق من الرموز من جانب العميل وخادم التفويض ، تم إرسال الرمز المميز في شكل مشفر مع العديد من المعلمات والتحقق منه على خادم التفويض. لم يكن هذا هو الخيار الأكثر ملاءمة ، حيث كان على كل تطبيق داخلي أن يصف طبقة كبيرة من المنطق ، وكانت قواعد بيانات الموظفين متزامنة تمامًا مع خادم التفويض.
بعد مرور بعض الوقت ، قررنا تبسيط مهمة التفويض المركزي. تم نقل SSO إلى الموازن. بمساعدة OpenResty ، تمت إضافة قالب إلى Lua يقوم بفحص الرموز المميزة ، ويعرف التطبيق الذي سينتقل إليه الطلب ، ويمكنه التحقق مما إذا كان هناك وصول هناك. ساهم هذا النهج إلى حد كبير في تبسيط مهمة التحكم في الوصول إلى التطبيقات الداخلية - في كود كل تطبيق ، لم يعد من الضروري وصف المنطق الإضافي. ونتيجة لذلك ، أغلقنا حركة المرور خارجيًا ، ولم يكن التطبيق نفسه يعرف شيئًا عن التفويض.
ومع ذلك ، بقيت مشكلة واحدة دون حل. ماذا عن التطبيقات التي تحتاج إلى معلومات عن الموظفين؟ كان من الممكن كتابة واجهة برمجة تطبيقات لخدمة التفويض ، ولكن بعد ذلك سيتعين عليك إضافة منطق إضافي لكل تطبيق من هذا القبيل. بالإضافة إلى ذلك ، أردنا التخلص من الاعتماد على أحد تطبيقاتنا المكتوبة ذاتيًا ، والموجهة في المستقبل للترجمة إلى OpenSource ، على خادم التفويض الداخلي الخاص بنا. سنتحدث عنها في وقت آخر. كان حل كلتا المشكلتين هو بروتوكول OAuth.
للمعايير المشتركة
OAuth هو معيار تفويض مفهوم ومقبول بشكل عام ، ولكن نظرًا لأن وظيفته فقط ليست كافية ، فقد بدأوا على الفور في التفكير في OpenID Connect (OIDC). OIDC نفسه هو التطبيق الثالث لمعيار المصادقة المفتوحة ، والذي يتدفق إلى وظيفة إضافية عبر بروتوكول OAuth 2.0 (بروتوكول تفويض مفتوح). يغلق هذا الحل مشكلة نقص البيانات حول المستخدم النهائي ، كما أنه يجعل من الممكن تغيير موفر التفويض.
ومع ذلك ، لم نختار مزودًا معينًا وقررنا إضافة تكامل مع OIDC لخادم التفويض الحالي الخاص بنا. لصالح هذا القرار كان حقيقة أن OIDC مرن للغاية من حيث تفويض المستخدم النهائي. وبالتالي ، كان من الممكن تنفيذ دعم OIDC على خادم التفويض الحالي.
طريقتنا في تنفيذ خادم OIDC الخاص بنا
1) جلب البيانات إلى النموذج المطلوب
لدمج OIDC ، من الضروري إحضار بيانات المستخدم الحالية في نموذج يمكن فهمه بالمعيار. في OIDC يسمى هذا المطالبات. المطالبات هي في الأساس حقول نهائية في قاعدة بيانات المستخدم (الاسم والبريد الإلكتروني والهاتف وما إلى ذلك). موجود ، وكل ما لم يتم تضمينه في هذه القائمة يعتبر مخصصًا. لذلك ، فإن النقطة الأولى التي يجب الانتباه إليها إذا كنت ترغب في اختيار مزود OIDC موجود هي إمكانية التخصيص الملائم للعلامات التجارية الجديدة.
يتم دمج مجموعة العلامات المميزة في المجموعة الفرعية التالية - النطاق. أثناء التفويض ، لا يُطلب الوصول إلى علامات تجارية محددة ، ولكن إلى نطاقات ، حتى إذا لم تكن هناك حاجة إلى بعض العلامات التجارية من النطاق.
2) تنفيذ المنح اللازمة
الجزء التالي من تكامل OIDC هو اختيار وتنفيذ أنواع التفويض ، ما يسمى بالمنح. سيعتمد السيناريو الإضافي للتفاعل بين التطبيق المحدد وخادم التفويض على المنحة المختارة. يظهر مخطط نموذجي لاختيار المنحة المناسبة في الشكل أدناه.
في تطبيقنا الأول ، استخدمنا المنحة الأكثر شيوعًا ، رمز التفويض. اختلافه عن غيره أنه من ثلاث درجات ، أي. يخضع لاختبارات إضافية. أولاً ، يقوم المستخدم بتقديم طلب للحصول على إذن التفويض ، ويتلقى رمزًا مميزًا - رمز التفويض ، ثم باستخدام هذا الرمز المميز ، كما لو كان مع تذكرة سفر ، يطلب رمز وصول. تعتمد جميع التفاعلات الرئيسية لنص التفويض هذا على عمليات إعادة التوجيه بين التطبيق وخادم التفويض. يمكنك قراءة المزيد عن هذه المنحة .
يلتزم بروتوكول OAuth بمفهوم أن رموز الوصول التي تم الحصول عليها بعد التفويض يجب أن تكون مؤقتة ويجب أن تتغير ، ويفضل أن يكون ذلك كل 10 دقائق في المتوسط. منحة كود التفويض عبارة عن عملية تحقق من ثلاث خطوات من خلال عمليات إعادة التوجيه ، كل 10 دقائق لتشغيل هذه الخطوة ، بصراحة ، ليست المهمة الأكثر متعة للعيون. لحل هذه المشكلة ، هناك منحة أخرى - Refresh Token ، والتي استخدمناها أيضًا في بلدنا. كل شيء أسهل هنا. أثناء التحقق من منحة أخرى ، بالإضافة إلى رمز الوصول الرئيسي ، يتم إصدار رمز آخر - Refresh Token ، والذي يمكن استخدامه مرة واحدة فقط ويكون عمره عادةً أطول بكثير. باستخدام رمز التحديث هذا ، عند انتهاء مدة البقاء (TTL) لرمز الوصول الرئيسي ، سيصل طلب رمز وصول جديد إلى نقطة نهاية منحة أخرى. تتم إعادة تعيين رمز التحديث المستخدم على الفور إلى الصفر. يتكون هذا الفحص من خطوتين ويمكن إجراؤه في الخلفية ، بشكل غير محسوس للمستخدم.
3) إعداد تنسيقات إخراج البيانات المخصصة
بعد تنفيذ المنح المختارة ، يعمل التفويض ، تجدر الإشارة إلى الحصول على بيانات حول المستخدم النهائي. يحتوي OIDC على نقطة نهاية منفصلة لذلك ، حيث يمكنك طلب بيانات المستخدم باستخدام رمز الوصول الحالي الخاص بك وما إذا كان محدثًا. وإذا لم تتغير بيانات المستخدم كثيرًا ، وتحتاج إلى متابعة البيانات الحالية عدة مرات ، فيمكنك الوصول إلى حل مثل رموز JWT. هذه الرموز المميزة مدعومة أيضًا بالمعيار. يتكون رمز JWT نفسه من ثلاثة أجزاء: الرأس (معلومات حول الرمز المميز) ، الحمولة (أي بيانات ضرورية) والتوقيع (التوقيع ، يتم توقيع الرمز المميز بواسطة الخادم ويمكنك لاحقًا التحقق من مصدر توقيعه).
في تطبيق OIDC ، يُطلق على رمز JWT اسم id_token. يمكن طلبها جنبًا إلى جنب مع رمز وصول عادي وكل ما تبقى هو التحقق من التوقيع. يحتوي خادم التفويض على نقطة نهاية منفصلة لهذا مع مجموعة من المفاتيح العامة في التنسيق . وبالحديث عن هذا ، تجدر الإشارة إلى أن هناك نقطة نهاية أخرى ، والتي تعتمد على المعيار يعكس التكوين الحالي لخادم OIDC. يحتوي على جميع عناوين نقطة النهاية (بما في ذلك عنوان حلقة المفاتيح العامة المستخدمة للتوقيع) ، والعلامات التجارية والنطاقات المدعومة ، وخوارزميات التشفير المستخدمة ، والمنح المدعومة ، وما إلى ذلك.
على سبيل المثال على جوجل:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}وبالتالي ، باستخدام id_token ، يمكنك نقل جميع السمات المميزة الضرورية إلى حمولة الرمز المميز وعدم الاتصال بخادم التفويض في كل مرة لطلب بيانات المستخدم. عيب هذا الأسلوب هو أن التغيير في بيانات المستخدم من الخادم لا يأتي على الفور ، ولكن مع رمز وصول جديد.
نتائج التنفيذ
لذلك ، بعد تنفيذ خادم OIDC الخاص بنا وتكوين الاتصالات معه على جانب التطبيق ، قمنا بحل مشكلة نقل المعلومات حول المستخدمين.
نظرًا لأن OIDC هو معيار مفتوح ، فلدينا خيار اختيار مزود حالي أو تنفيذ خادم. لقد جربنا Keycloak ، والذي اتضح أنه ملائم جدًا للتهيئة ، بعد إعداد وتغيير تكوينات الاتصال على جانب التطبيق ، فهو جاهز للعمل. على جانب التطبيق ، كل ما تبقى هو تغيير تكوينات الاتصال.
نتحدث عن الحلول الموجودة
داخل مؤسستنا ، كأول خادم OIDC ، قمنا بتجميع التنفيذ الخاص بنا ، والذي تم استكماله حسب الضرورة. بعد مراجعة تفصيلية للحلول الأخرى الجاهزة ، يمكننا القول أن هذه نقطة خلافية. لصالح قرار تنفيذ الخادم الخاص بهم ، كانت هناك مخاوف من جانب مقدمي الخدمة في غياب الوظائف اللازمة ، فضلاً عن وجود نظام قديم حيث كانت هناك تصاريح مخصصة مختلفة لبعض الخدمات والكثير جدًا من البيانات حول الموظفين مخزنة بالفعل. ومع ذلك ، في التطبيقات الجاهزة ، هناك وسائل الراحة للتكامل. على سبيل المثال ، لدى Keycloak نظام إدارة المستخدم الخاص بها ويتم تخزين البيانات فيه مباشرة ، ولن يكون من الصعب تجاوز المستخدمين لديك هناك. للقيام بذلك ، لدى Keycloak واجهة برمجة تطبيقات تسمح لك بتنفيذ جميع إجراءات النقل الضرورية بشكل كامل.
مثال آخر على التنفيذ المعتمد والمثير للاهتمام ، في رأيي ، هو Ory Hydra. إنه ممتع لأنه يتكون من مكونات مختلفة. للتكامل ، ستحتاج إلى ربط خدمة إدارة المستخدم الخاصة بك بخدمة التفويض الخاصة بهم وتمديدها حسب الحاجة.
Keycloak و Ory Hydra ليسا الحلول الجاهزة الوحيدة. من الأفضل اختيار تطبيق معتمد من مؤسسة OpenID. عادة ما يكون لهذه الحلول شارة شهادة OpenID.
لا تنسَ أيضًا مزودي الخدمة المدفوعة الحاليين إذا كنت لا تريد الاحتفاظ بخادم OIDC الخاص بك. اليوم هناك العديد من الخيارات الجيدة.
ما هي الخطوة التالية
في المستقبل القريب ، سنغلق حركة المرور على الخدمات الداخلية بطريقة مختلفة. نحن نخطط لنقل SSO الحالي الخاص بنا على الموازن باستخدام OpenResty إلى وكيل يعتمد على OAuth. يوجد بالفعل العديد من الحلول الجاهزة هنا ، على سبيل المثال:
مواد إضافية
- خدمة جيدة للتحقق من صحة رموز JWT
- قائمة تطبيقات OIDC المعتمدة
المصدر: www.habr.com