تبسيط دمج مصادقة SAML للمطورين

الدخول الأحادي (SSO) هو عنصر أساسي للتطبيقات الحديثة، وSAML تمكّن من مصادقة آمنة وسهلة عبر أنظمة الهوية في المؤسسات. يبسّط هذا الدليل SAML للمطورين والمصممين بخطوات واضحة وأمثلة عملية لمساعدتك على تنفيذها بكفاءة.

ما هي مصادقة SAML وتطبيقات SAML؟#

لغة تعليمات تأكيد الأمان (SAML) هي معيار يعتمد على XML يُستخدم لتبادل بيانات المصادقة والتفويض بين طرفين رئيسيين: مزود الهوية (IdP) و مزود الخدمة (SP). إنها حل شائع للدخول الأحادي (SSO) في المؤسسات، مما يسهل على المستخدمين المؤسسيين من خلال السماح لهم بتسجيل الدخول مرة واحدة والوصول إلى تطبيقات متعددة.

مزود الهوية (IdP) مسؤول عن إدارة والتحقق من بيانات اعتماد المستخدم، مثل أسماء المستخدمين وكلمات المرور. عندما يحاول المستخدم الوصول إلى خدمة محمية، يؤكد الـ IdP هويته ويرسل هذا التأكيد إلى الخدمة.

• مثال: تخيل أنك تعمل في شركة كبيرة تستخدم Microsoft Azure AD لإدارة حسابات الموظفين. عندما تريد تسجيل الدخول إلى Salesforce، يعمل Azure AD كمزود هوية (IdP). يتحقق من بيانات اعتمادك ويُعلم Salesforce أنك مخول بالوصول إليه.

مزود الخدمة (SP) هو التطبيق أو الخدمة التي يحاول المستخدمون الوصول إليها فعليًا. يعتمد على الـ IdP للتعامل مع عبء المصادقة.

• مثال: استمرارًا للموقف السابق، Salesforce هو مزود الخدمة (SP). يعتمد على Microsoft Azure AD (مزود الهوية) لتأكيد هويتك. بمجرد أن يشهد Azure AD لك، يسمح لك Salesforce بالدخول.

عند الحديث عن "تطبيق SAML"، يشير الناس عادة إلى الـ SP.

باستخدام بروتوكول SAML، يمكنك إعداد خدمتك كمزود هوية (IdP) لدعم تكامل التطبيقات (مثل Azure Ad / Google Workspace)؛ أو كمزود خدمة (SP) (مثل Salesforce / Slack) لدعم الدخول الأحادي للمستخدمين.

تأكيد SAML هو قلب بروتوكول SAML. إنه "ملاحظة" رقمية ينشئها الـ IdP وتُرسل إلى SP كتب فيها: "لقد أكدت هوية هذا المستخدم." بعد ذلك، سنغطي كيف تعمل العملية لكل من IdP وSP.

عند العمل كمزود هوية SAML#

عندما تعمل خدمتك كمزود هوية (IdP)، فأنت تمكّن المصادقة عبر SAML لعدة تطبيقات. هذا يسمح للمستخدمين بالوصول إلى خدمات مختلفة من خلال هوية مؤسسية واحدة.

فيما يلي سير عمل نموذجي للدخول الأحادي SAML لـ IdP:

1. يحاول المستخدم الوصول إلى تطبيق (SP) مثل Salesforce.
2. يعيد التطبيق توجيه المستخدم إلى IdP الخاص بك للمصادقة.
3. يدخل المستخدم بيانات اعتماده في صفحة تسجيل الدخول الخاصة بـ IdP.
4. يتحقق الـ IdP من بيانات الاعتماد.
5. إذا تم التحقق من بيانات الاعتماد، يرسل IdP تأكيد SAML إلى SP.
6. يعالج SP التأكيد ويتحقق من صلاحيته ويسمح للمستخدم بالوصول.

عند العمل كمزود خدمة SAML#

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

فيما يلي سير عمل لدخول SSO بدأه مزود الخدمة (SP):

1. يحاول المستخدم تسجيل الدخول إلى تطبيقك.
2. ينشئ تطبيقك طلب SAML ويعيد توجيه المستخدم إلى صفحة تسجيل الدخول لدى IdP.
3. يسجل المستخدم الدخول في IdP (أو يتجاوز هذه الخطوة إذا كان قد سجل الدخول مسبقًا).
4. يتحقق الـ IdP من هوية المستخدم، وبمجرد التأكيد يقوم بتجميع تفاصيل المستخدم في تأكيد SAML.
5. يرسل الـ IdP التأكيد مرة أخرى إلى تطبيقك.
6. يتحقق تطبيقك من التأكيد، وإذا كان صالحًا، يحصل المستخدم على إذن للوصول إلى التطبيق.

المعلمات الرئيسية في الدخول الأحادي عبر SAML#

لنجاح عملية دخول الأحادي SAML، يجب أن يشارك كل من IdPs وSPs معلمات محددة. إليك نظرة على الأساسيات:

معلمات من IdP#

1. معرّف كيان IdP: معرف فريد لـ IdP في اتصالات SAML، مثل بطاقة اسم رقمية.
2. عنوان URL للدخول الأحادي (SSO): نقطة النهاية (رابط) لتسجيل الدخول حيث يعيد SP توجيه المستخدمين للمصادقة.
3. شهادة X.509: مفتاح عام يُستخدم لتوقيع تأكيد SAML، لضمان أمانه. هذا هو "الختم" الذي يثبت الأصالة.

نصيحة: إذا كان IdP الخاص بك يقدم رابط بيانات تعريف SAML (SAML Metadata URL)، تصبح الأمور أسهل. يحتوي هذا الرابط على جميع المعلومات الضرورية (مثل الشهادات، روابط SSO، ومعرّف كيان IdP) في مكان واحد. يقلل من مخاطر الأخطاء الناتجة عن النسخ واللصق يدويًا ويلغي عناء تحديث ملفات الشهادات يدويًا.

معلمات من SP#

1. معرّف كيان SP: معرف فريد لـ SP، مماثل لمعّرف كيان IdP.
2. رابط خدمة مستهلك التأكيد (ACS): هذه نقطة النهاية لدى SP حيث يتوقع استقبال تأكيد SAML من IdP.
3. RelayState (اختياري): تُستخدم لتمرير البيانات أثناء عملية SAML، مثل الرابط الذي حاول المستخدم زيارته في الأصل.

تعيين سمات SAML والتشفير#

1. تنسيق معرف الاسم (NameID Format): يحدد تنسيق معرف المستخدم (مثلاً: عنوان البريد الإلكتروني أو اسم المستخدم).
2. سمات SAML: هذه تفاصيل إضافية عن المستخدم (مثل الأدوار، البريد الإلكتروني، أو القسم) يرسلها الـ IdP إلى SP.
   • مثال: إذا تضمن تأكيد SAML الموقّع من IdP كلاً من email ([email protected])، و role (admin)، و department (engineering). يمكن أن يستخدم SP قيمة role لإعطاء صلاحيات الإدارة أو department لتجميع المستخدم ضمن الفريق المناسب. لذا لجلب هذه البيانات الأساسية، يجب أن يتفق كل من IdP وSP على كيفية تعيين السمات. على سبيل المثال: قد يعرّف IdP "department" كـ team، فيما يتوقع SP تسميتها group. يضمن التعيين السليم وضوحًا في الاتصال.
3. تأكيدات مشفرة (اختياري): لحماية بيانات المصادقة الحساسة، يمكن تشفير تأكيدات SAML.
   • دور IdP: يشفر التأكيد باستخدام المفتاح العام لـ SP.
   • دور SP: يفك تشفير التأكيد باستخدام مفتاحه الخاص ليقرأ تفاصيل المستخدم.

الآن يجب أن يكون لديك المعلومات اللازمة لإعداد اتصال SAML. لربط Salesforce (مزود خدمة) مع Azure AD (مزود هوية)، اتبع هذه الخطوات:

• احصل على معرّف كيان IdP، رابط الدخول الأحادي (SSO)، والشهادة من Azure AD وادخلهم في إعدادات Salesforce.
• زوّد Azure AD بمعرّف كيان SP ورابط ACS الخاص بـ Salesforce.

Logto تجعل دمج SAML بسيطًا#

يمكن لـ Logto أن تعمل كـ IdP أو SP لدعم الدخول الأحادي SAML في تطبيقاتك.

استخدام Logto كمزود هوية SAML#

تسمح Logto للتطبيقات الأخرى بالاعتماد عليها لمصادقة الهوية الموحّدة، وتدعم المصادقة متعددة العوامل (MFA) لتعزيز الأمان.

1. إنشاء تطبيق Logto اذهب إلى Logto Console > التطبيقات وأنشئ تطبيق SAML جديد.
2. إعداد معلمات SAML أضف إلى التطبيق رابط خدمة مستهلك التأكيد (ACS) و معرف كيان SP الخاص بمزود الخدمة.
3. توفير رابط بيانات التعريف توفر Logto رابط بيانات تعريف IdP يمكن لـ SPs استخدامه لاسترداد التفاصيل الأساسية تلقائيًا مثل روابط SSO والشهادات.
4. إعدادات متقدمة (اختياري)
   • يمكنك إنشاء عدة شهادات جديدة مع بصمات الإصبع وتحديد تواريخ انتهاء الصلاحية، لكن يمكنك تفعيل شهادة واحدة فقط في آن واحد.
   • عدّل تنسيق معرف الاسم بما يناسب متطلبات عملك.
   • فعّل تشفير تأكيدات SAML بنسخ ولصق شهادة x509 من مزود الخدمة لتشفير التأكيدات.
5. تعيين السمات (اختياري) يمكنك بسهولة تخصيص كيفية مشاركة سمات المستخدم مع مزودي الخدمة (SPs).

للحصول على إرشادات مفصّلة، قم بزيارة الوثائق الرسمية هنا: تطبيق SAML

استخدام Logto كمزود خدمة SAML#

تدمج Logto كذلك مع أي مزود هوية مؤسسي عبر بروتوكولي SAML أو OIDC. سواء كنت تفعّل SSO بدأ من SP لصفحات تسجيل الدخول الموحد أو تهيئ SSO بدأ من IdP، العملية واضحة وسهلة.

1. إنشاء موصل مؤسسي اذهب إلى Logto Console > الدخول الأحادي المؤسسي وأنشئ موصل مؤسسي جديد. اختر بروتوكول SAML كمعيار.
2. إعداد معلمات SAML قدّم إما رابط بيانات التعريف أو ملف بيانات التعريف XML من مزود الهوية (IdP). إذا لم تتوفر البيانات، يمكنك التحويل للإعداد اليدوي بإدخال معرّف كيان IdP ورابط SSO ورفع شهادة التوقيع.
3. مشاركة رابط ACS ومعرّف كيان SP زوّد مزود الهوية الخاص بك بـ رابط ACS و معرف كيان SP لـ Logto لإتمام الإعداد.
4. تعيين السمات (اختياري) قم بضبط خرائط بيانات المستخدم (مثل البريد الإلكتروني أو الأسماء) لضمان نقل المعلومات بشكل صحيح بين IdP وLogto.
5. إضافة نطاقات بريد إلكتروني مؤسسية في تبويب “تجربة SSO” للموصل المؤسسي، أضف واحدًا أو أكثر من نطاقات البريد الإلكتروني. يضمن ذلك أن المستخدمين الذين لديهم تلك النطاقات فقط يمكنهم المصادقة عبر SSO.
6. تفعيل SSO بدأ من IdP (اختياري) قم بتفعيل الدخول الأحادي عبر IdP فقط إذا كان ذلك مطلوبًا من قبل عملائك المؤسسيين. تتيح هذه الميزة للمستخدمين تسجيل الدخول مباشرة من لوحة معلومات IdP إلى تطبيقاتك.

للحصول على إرشادات مفصلة، قم بزيارة الوثائق الرسمية هنا: وثائق SSO المؤسسي.

خاتمة#

توفر SAML طريقة موحّدة وآمنة للدخول الأحادي، مما يجعل المصادقة أكثر سلاسة. Logto تبسّط العملية سواء أعددتها كمزود هوية (IdP) أو مزود خدمة (SP). مع واجهتها السهلة ودعمها للإصدارات السحابية و المفتوحة المصدر، تزيل Logto التعقيدات من دمج SAML. بمجرد تكوين بعض المعلمات، يمكنك ربط خدماتك بأي IdP أو SP يدعم SAML والتركيز على تقديم تجربة ممتازة لمستخدميك.