الدخول الأحادي (SSO) هو عنصر أساسي للتطبيقات الحديثة، و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.
إذا كانت خدمتك هي الـ SP، ستدمج مع مجموعة متنوعة من مزودي الهوية لتوفير إمكانيات الدخول الأحادي للمستخدمين. هذا يسمح للمستخدمين المؤسسيين من مؤسسات متعددة أو مستأجرين مختلفين بالوصول لتطبيقك بأمان وكفاءة.
فيما يلي سير عمل لدخول SSO بدأه مزود الخدمة (SP):
يحاول المستخدم تسجيل الدخول إلى تطبيقك.
ينشئ تطبيقك طلب SAML ويعيد توجيه المستخدم إلى صفحة تسجيل الدخول لدى IdP.
يسجل المستخدم الدخول في IdP (أو يتجاوز هذه الخطوة إذا كان قد سجل الدخول مسبقًا).
يتحقق الـ IdP من هوية المستخدم، وبمجرد التأكيد يقوم بتجميع تفاصيل المستخدم في تأكيد SAML.
يرسل الـ IdP التأكيد مرة أخرى إلى تطبيقك.
يتحقق تطبيقك من التأكيد، وإذا كان صالحًا، يحصل المستخدم على إذن للوصول إلى التطبيق.
معرّف كيان IdP: معرف فريد لـ IdP في اتصالات SAML، مثل بطاقة اسم رقمية.
عنوان URL للدخول الأحادي (SSO): نقطة النهاية (رابط) لتسجيل الدخول حيث يعيد SP توجيه المستخدمين للمصادقة.
شهادة X.509: مفتاح عام يُستخدم لتوقيع تأكيد SAML، لضمان أمانه. هذا هو "الختم" الذي يثبت الأصالة.
نصيحة: إذا كان IdP الخاص بك يقدم رابط بيانات تعريف SAML (SAML Metadata URL)، تصبح الأمور أسهل. يحتوي هذا الرابط على جميع المعلومات الضرورية (مثل الشهادات، روابط SSO، ومعرّف كيان IdP) في مكان واحد. يقلل من مخاطر الأخطاء الناتجة عن النسخ واللصق يدويًا ويلغي عناء تحديث ملفات الشهادات يدويًا.
تنسيق معرف الاسم (NameID Format): يحدد تنسيق معرف المستخدم (مثلاً: عنوان البريد الإلكتروني أو اسم المستخدم).
سمات SAML: هذه تفاصيل إضافية عن المستخدم (مثل الأدوار، البريد الإلكتروني، أو القسم) يرسلها الـ IdP إلى SP.
مثال: إذا تضمن تأكيد SAML الموقّع من IdP كلاً من email ([email protected])، و role (admin)، و department (engineering). يمكن أن يستخدم SP قيمة role لإعطاء صلاحيات الإدارة أو department لتجميع المستخدم ضمن الفريق المناسب. لذا لجلب هذه البيانات الأساسية، يجب أن يتفق كل من IdP وSP على كيفية تعيين السمات. على سبيل المثال: قد يعرّف IdP "department" كـ team، فيما يتوقع SP تسميتها group. يضمن التعيين السليم وضوحًا في الاتصال.
تأكيدات مشفرة (اختياري): لحماية بيانات المصادقة الحساسة، يمكن تشفير تأكيدات SAML.
دور IdP: يشفر التأكيد باستخدام المفتاح العام لـ SP.
دور SP: يفك تشفير التأكيد باستخدام مفتاحه الخاص ليقرأ تفاصيل المستخدم.
الآن يجب أن يكون لديك المعلومات اللازمة لإعداد اتصال SAML. لربط Salesforce (مزود خدمة) مع Azure AD (مزود هوية)، اتبع هذه الخطوات:
احصل على معرّف كيان IdP، رابط الدخول الأحادي (SSO)، والشهادة من Azure AD وادخلهم في إعدادات Salesforce.
زوّد Azure AD بمعرّف كيان SP ورابط ACS الخاص بـ Salesforce.
تدمج Logto كذلك مع أي مزود هوية مؤسسي عبر بروتوكولي SAML أو OIDC. سواء كنت تفعّل SSO بدأ من SP لصفحات تسجيل الدخول الموحد أو تهيئ SSO بدأ من IdP، العملية واضحة وسهلة.
إعداد معلمات SAML
قدّم إما رابط بيانات التعريف أو ملف بيانات التعريف XML من مزود الهوية (IdP). إذا لم تتوفر البيانات، يمكنك التحويل للإعداد اليدوي بإدخال معرّف كيان IdP ورابط SSO ورفع شهادة التوقيع.
مشاركة رابط ACS ومعرّف كيان SP
زوّد مزود الهوية الخاص بك بـ رابط ACS و معرف كيان SP لـ Logto لإتمام الإعداد.
تعيين السمات (اختياري)
قم بضبط خرائط بيانات المستخدم (مثل البريد الإلكتروني أو الأسماء) لضمان نقل المعلومات بشكل صحيح بين IdP وLogto.
إضافة نطاقات بريد إلكتروني مؤسسية
في تبويب “تجربة SSO” للموصل المؤسسي، أضف واحدًا أو أكثر من نطاقات البريد الإلكتروني. يضمن ذلك أن المستخدمين الذين لديهم تلك النطاقات فقط يمكنهم المصادقة عبر SSO.
تفعيل SSO بدأ من IdP (اختياري)
قم بتفعيل الدخول الأحادي عبر IdP فقط إذا كان ذلك مطلوبًا من قبل عملائك المؤسسيين. تتيح هذه الميزة للمستخدمين تسجيل الدخول مباشرة من لوحة معلومات IdP إلى تطبيقاتك.
للحصول على إرشادات مفصلة، قم بزيارة الوثائق الرسمية هنا: وثائق SSO المؤسسي.
توفر SAML طريقة موحّدة وآمنة للدخول الأحادي، مما يجعل المصادقة أكثر سلاسة. Logto تبسّط العملية سواء أعددتها كمزود هوية (IdP) أو مزود خدمة (SP). مع واجهتها السهلة ودعمها للإصدارات السحابية و المفتوحة المصدر، تزيل Logto التعقيدات من دمج SAML. بمجرد تكوين بعض المعلمات، يمكنك ربط خدماتك بأي IdP أو SP يدعم SAML والتركيز على تقديم تجربة ممتازة لمستخدميك.
