جریان IdP-Initiated SSO
در این جریان، کاربر ابتدا به پورتال IdP مراجعه و در آنجا لاگین میکند. سپس از فهرست اپلیکیشنهای موجود در پورتال، سرویس مورد نظر خود را انتخاب مینماید. IdP بدون دریافت AuthnRequest قبلی، مستقیماً یک SAML Response حاوی Assertion تولید و از طریق مرورگر کاربر به ACS Endpoint مربوط به SP ارسال میکند.
این جریان سادهتر بوده اما از نظر امنیتی ضعیفتر محسوب میشود. چون AuthnRequest وجود ندارد، SP نمیتواند درخواست اولیه خود را با پاسخ دریافتی تطبیق دهد و این موضوع آسیبپذیری در برابر حملات CSRF و Replay ایجاد میکند. بهترین رویههای امنیتی استفاده از SP-Initiated SSO را توصیه مینمایند.
SAML Bindings: روشهای انتقال پیام
SAML Binding مشخص میکند پیامهای SAML چگونه از طریق پروتکلهای ارتباطی منتقل شوند. مهمترین Bindingها عبارتاند از:
HTTP-Redirect Binding پیام SAML را بهصورت فشردهشده و Base64-encode شده در پارامتر URL قرار میدهد. این Binding برای پیامهای کوچک مانند AuthnRequest مناسب بوده اما برای پیامهای بزرگ مانند SAML Response (به دلیل محدودیت طول URL) قابل استفاده نیست.
HTTP-POST Binding پیام SAML را در یک فرم HTML مخفی قرار میدهد و با JavaScript آن را بهصورت خودکار به مقصد ارسال مینماید. این Binding برای انتقال SAML Response و Assertionهای بزرگ ایدهآل محسوب میشود.
SOAP Binding ارتباط مستقیم سرور به سرور (Back-channel) را امکانپذیر میسازد. این Binding برای سناریوهایی مانند Artifact Resolution و Single Logout Back-channel استفاده خواهد شد.
Artifact Binding یک مکانیزم غیرمستقیم ارائه میدهد. به جای ارسال مستقیم Assertion از طریق مرورگر، IdP یک شناسه کوتاه (Artifact) ارسال میکند و SP با یک درخواست مستقیم SOAP به IdP، Assertion واقعی را دریافت مینماید. این روش از قرار گرفتن Assertion در مرورگر جلوگیری کرده و امنیت بالاتری فراهم میسازد.
فدراسیون هویت با SAML: اتصال سازمانها
یکی از قدرتمندترین قابلیتهای SAML، امکانسازی فدراسیون هویت (Identity Federation) بین سازمانهای مختلف است. فدراسیون هویت به سازمانها اجازه میدهد بدون اشتراکگذاری پایگاه داده کاربران، به هویتهای یکدیگر اعتماد کنند.
مفهوم Circle of Trust
در مدل فدراسیون SAML، مجموعهای از سازمانها توافق میکنند که Assertionهای یکدیگر را بپذیرند و این مجموعه یک Circle of Trust (حلقه اعتماد) تشکیل میدهد. هر سازمان IdP خود را مدیریت میکند و کاربران آن سازمان با اعتبارنامههای محلی خود احراز هویت میشوند. وقتی کاربری از سازمان A بخواهد به سرویسی در سازمان B دسترسی پیدا کند، IdP سازمان A یک Assertion صادر مینماید و SP سازمان B بر اساس توافق فدراسیون، آن Assertion را میپذیرد.
این مدل در سناریوهای متعددی کاربرد دارد. شرکتهای مادر و زیرمجموعه میتوانند بدون ادغام سیستمهای هویت خود، دسترسی یکپارچه به منابع مشترک فراهم کنند. دانشگاهها و مؤسسات آموزشی از طریق فدراسیونهایی مانند eduroam و InCommon به دانشجویان اجازه میدهند با حساب دانشگاه خود به منابع سایر مؤسسات دسترسی پیدا نمایند. سازمانهای دولتی نیز از فدراسیون هویت برای ارائه خدمات بینسازمانی بدون ایجاد حسابهای کاربری تکراری بهره میبرند.
مدیریت NameID و Account Linking
NameID شناسهای است که IdP برای معرفی کاربر به SP استفاده میکند. SAML چندین فرمت NameID تعریف کرده که هر کدام برای سناریوی خاصی مناسب هستند.
فرمت emailAddress آدرس ایمیل کاربر را بهعنوان شناسه استفاده میکند و سادهترین و رایجترین روش محسوب میشود. فرمت persistent یک شناسه تصادفی و ثابت ایجاد میکند که حفظ حریم خصوصی کاربر را تضمین نموده زیرا اطلاعات شخصی را فاش نمیسازد. فرمت transient شناسهای موقت و یکبارمصرف تولید میکند که برای سناریوهای ناشناس یا با حداقل اشتراک اطلاعات مناسب خواهد بود.
Account Linking فرآیندی است که حساب کاربری در سمت SP با هویت ارائهشده توسط IdP مرتبط میشود. این ارتباط میتواند بهصورت خودکار (بر اساس ویژگی مشترک مانند ایمیل) یا دستی (با تأیید کاربر) انجام شود.
امنیت در SAML: تهدیدها، آسیبپذیریها و راهکارها
پروتکل SAML مکانیزمهای امنیتی قدرتمندی در خود دارد، اما پیادهسازی نادرست میتواند آسیبپذیریهای بحرانی ایجاد کند. شناخت این تهدیدها و راهکارهای مقابله برای هر سازمانی که از SAML SSO استفاده میکند ضروری است.
امضای دیجیتال و رمزنگاری XML
امضای دیجیتال مهمترین مکانیزم امنیتی SAML محسوب میشود. IdP با کلید خصوصی خود Assertion (و اختیاراً کل SAML Response) را امضا میکند و SP با استفاده از کلید عمومی IdP (که از متادیتا دریافت کرده) اصالت و یکپارچگی سند را تأیید مینماید.
رمزنگاری Assertion لایه محرمانگی را اضافه میکند. IdP میتواند Assertion را با کلید عمومی SP رمزنگاری کند تا حتی اگر پیام در مسیر رهگیری شود، محتوای آن قابل خواندن نباشد. SP تنها با کلید خصوصی خود قادر به رمزگشایی خواهد بود.
آسیبپذیری XML Signature Wrapping
یکی از خطرناکترین آسیبپذیریهای تاریخی SAML، حمله XML Signature Wrapping (XSW) بوده است. در این حمله، مهاجم ساختار XML سند SAML را دستکاری میکند بهگونهای که امضای دیجیتال همچنان معتبر باقی بماند اما SP بخش دستکاریشده را به جای بخش اصلی پردازش نماید. مهاجم یک کپی از Assertion اصلی امضاشده را در سند نگه میدارد (تا امضا معتبر بماند) و یک Assertion جعلی با اطلاعات هویتی متفاوت اضافه میکند. اگر SP هنگام اعتبارسنجی، Assertion اشتباهی را بخواند، مهاجم موفق به جعل هویت خواهد شد.
مقابله با این حمله نیازمند اعتبارسنجی دقیق ساختار XML و اطمینان از این موضوع است که SP دقیقاً همان بخشی از سند را پردازش میکند که امضای دیجیتال آن را پوشش داده است. استفاده از کتابخانههای SAML بهروز و آزمودهشده (به جای پیادهسازی دستی) بهترین راهکار پیشگیری بهشمار میرود.
سایر تهدیدات امنیتی SAML
Replay Attack زمانی رخ میدهد که مهاجم یک SAML Response معتبر را رهگیری و مجدداً ارسال کند. استفاده از شرایط زمانی دقیق (NotBefore و NotOnOrAfter) و ذخیره شناسههای Assertion مصرفشده برای جلوگیری از پردازش مجدد، این حمله را خنثی میسازد.
Man-in-the-Middle تهدیدی است که استفاده اجباری از HTTPS برای تمام Endpointها و فعالسازی HSTS آن را ناکام میگذارد.
Denial of Service مبتنی بر XML حملهای است که مهاجم اسناد XML بسیار بزرگ یا با ساختار بازگشتی (XML Bomb) ارسال میکند تا منابع سرور را مصرف نماید. محدود کردن اندازه ورودی XML و غیرفعال کردن پردازش DTD و Entity خارجی از راهکارهای مقابله هستند.
مقایسه SAML با OIDC: کدام پروتکل برای سازمان شما مناسبتر است؟
انتخاب بین SAML و OpenID Connect یکی از تصمیمات مهم در طراحی معماری SSO سازمانی محسوب میشود. هر دو پروتکل مزایا و محدودیتهای خاص خود را دارند و درک دقیق تفاوتها به سازمانها کمک میکند تصمیم آگاهانهای بگیرند.
تفاوتهای بنیادین فنی
SAML بر پایه XML و SOAP بنا شده در حالی که OIDC از JSON و REST استفاده میکند. این تفاوت بنیادین پیامدهای عملی متعددی دارد. اسناد XML در SAML معمولاً حجیمتر از توکنهای JWT در OIDC هستند و پردازش آنها منابع بیشتری مصرف مینماید. از سوی دیگر، XML Schema امکان اعتبارسنجی دقیق ساختار سند را فراهم کرده که در سناریوهای با الزامات انطباقی بالا ارزشمند تلقی میشود.
OIDC با ارائه Discovery Endpoint فرآیند پیکربندی را بسیار خودکار کرده است. SAML نیز متادیتا دارد اما تبادل و پردازش آن معمولاً نیمهدستی انجام میشود. کتابخانهها و SDKهای مدرن برای OIDC فراوانتر و بهروزتر هستند، در حالی که اکوسیستم SAML بالغتر و در محیطهای سازمانی سنتی ریشهدارتر محسوب میشود.
سناریوهای مناسب هر پروتکل
SAML در سناریوهای زیر انتخاب بهتری خواهد بود: سازمانهایی با اپلیکیشنهای Legacy که فقط از SAML پشتیبانی میکنند، محیطهایی با الزامات انطباقی سختگیرانه که ساختار XML رسمی مورد نیاز است، فدراسیون بینسازمانی با شرکایی که زیرساخت SAML موجود دارند، و محیطهای آموزشی و دولتی که فدراسیونهای SAML مستقر و فعال وجود دارد.
OIDC در سناریوهای زیر برتری دارد: اپلیکیشنهای مدرن وب و موبایل، معماریهای Microservices و API-first، محیطهای ابری و Serverless، و سازمانهایی که از صفر شروع به پیادهسازی SSO میکنند.
رویکرد ترکیبی: بهترین هر دو دنیا
واقعیت بسیاری از سازمانها ترکیبی از اپلیکیشنهای قدیمی و جدید خواهد بود. بهترین رویکرد استفاده از یک Identity Provider مرکزی است که هر دو پروتکل را بهصورت همزمان پشتیبانی کند. سامانه احراز هویت نشانه (neshane.co) این قابلیت را فراهم کرده تا سازمانها بتوانند اپلیکیشنهای SAML و OIDC را از یک نقطه مرکزی مدیریت نمایند. اپلیکیشنهای قدیمی با SAML و اپلیکیشنهای جدید با OIDC متصل میشوند و کاربران تجربه SSO یکپارچهای دریافت خواهند کرد.
| ویژگی |
SAML 2.0 |
OpenID Connect |
| سال انتشار |
۲۰۰۵ |
۲۰۱۴ |
| فرمت داده |
XML |
JSON (JWT) |
| پروتکل انتقال |
HTTP-Redirect, HTTP-POST, SOAP |
REST/HTTP |
| اندازه پیام |
بزرگ |
کوچک |
| پشتیبانی موبایل |
محدود |
عالی |
| پشتیبانی SPA |
ندارد |
عالی (PKCE) |
| فدراسیون بینسازمانی |
بسیار قوی |
متوسط |
| اکوسیستم سازمانی |
بسیار بالغ |
در حال رشد سریع |
| پیچیدگی پیادهسازی |
بالا |
متوسط-پایین |
| Single Logout |
قوی (Front + Back channel) |
متوسط |
| پیکربندی خودکار |
متادیتا (نیمهدستی) |
Discovery (کاملاً خودکار) |
| یکپارچهسازی با FIDO2 |
AuthnContextClassRef |
amr Claim |
پیادهسازی عملی SAML SSO در سازمان
پیادهسازی SAML در محیط سازمانی فرآیندی چندمرحلهای بوده و نیازمند هماهنگی بین تیمهای مختلف فناوری اطلاعات و امنیت خواهد بود.
مرحله اول: آمادهسازی Identity Provider
اولین گام، استقرار و پیکربندی IdP مرکزی است. IdP باید با دایرکتوری سازمان (مانند Active Directory یا LDAP) یکپارچه شود تا حسابهای کاربری موجود بهصورت خودکار شناسایی شوند. تولید جفت کلید رمزنگاری (کلید خصوصی برای امضای Assertionها و گواهی عمومی برای اشتراک با SPها) در این مرحله انجام میگیرد. متادیتا IdP باید تولید و از طریق یک URL ثابت در دسترس قرار گیرد.
مرحله دوم: یکپارچهسازی Service Providerها
برای هر SP باید مراحل زیر طی شود: دریافت متادیتا SP (یا دریافت اطلاعات پیکربندی بهصورت دستی شامل EntityID و ACS URL)، ثبت SP در IdP و تنظیم NameID Format و Attributeهای مورد نیاز، ارسال متادیتا IdP به مدیر SP برای پیکربندی سمت اپلیکیشن، و نهایتاً آزمایش جریان SSO.
مرحله سوم: مدیریت Single Logout
پیادهسازی صحیح Single Logout (SLO) در SAML یکی از پیچیدهترین جنبههای عملیاتی محسوب میشود. SAML دو مکانیزم SLO تعریف کرده است.
در Front-Channel SLO، IdP هنگام خروج کاربر، مرورگر را بهصورت زنجیرهای به Logout Endpoint هر SP هدایت میکند. هر SP جلسه محلی کاربر را حذف و تأیید خروج را بازمیگرداند. این روش به فعال بودن مرورگر کاربر وابسته بوده و اگر کاربر مرورگر را ببندد، خروج از برخی SPها ناقص خواهد ماند.
در Back-Channel SLO، IdP مستقیماً یک درخواست SOAP به Logout Endpoint هر SP ارسال میکند. این روش قابلاعتمادتر بوده زیرا به مرورگر وابسته نیست، اما نیازمند دسترسی شبکهای مستقیم بین IdP و تمام SPها خواهد بود.
یکپارچهسازی SAML با FIDO2: ترکیب استاندارد بالغ با فناوری نوین
هرچند SAML پروتکلی قدیمیتر از FIDO2 محسوب میشود، یکپارچهسازی این دو فناوری نهتنها ممکن بلکه بسیار ارزشمند خواهد بود. SAML درباره «چگونگی» احراز هویت کاربر بینظر عمل کرده و این تصمیم را کاملاً به IdP واگذار مینماید. همین انعطافپذیری امکان جایگزینی رمز عبور سنتی با احراز هویت FIDO2 در لایه IdP را فراهم ساخته است.
AuthnContextClassRef: اعلام روش احراز هویت
SAML از عنصر AuthnContextClassRef در Authentication Statement برای مشخص کردن روش احراز هویت استفادهشده بهره میبرد. وقتی IdP از FIDO2 برای احراز هویت استفاده میکند، میتواند مقداری مانند urn:oasis:names:tc:SAML:2.0:ac:classes:FIDO یا یک URI سفارشی در این عنصر درج نماید. SP بر اساس این اطلاعات میتواند تصمیم بگیرد آیا سطح احراز هویت انجامشده برای دسترسی به منابع حساس کافی هست یا خیر.
Requested AuthnContext: الزام سطح احراز هویت
SP میتواند در AuthnRequest خود، سطح احراز هویت مورد انتظار را مشخص کند. مثلاً سیستم مالی سازمان میتواند درخواست کند که IdP حتماً کاربر را با روشی در سطح urn:oasis:names:tc:SAML:2.0:ac:classes:FIDO یا بالاتر احراز هویت نماید. اگر کاربر قبلاً فقط با رمز عبور ساده وارد شده باشد، IdP از او میخواهد مجدداً با کلید امنیتی FIDO2 احراز هویت شود. این مکانیزم Step-Up Authentication امکان اعمال سیاستهای امنیتی متناسب با حساسیت هر سرویس را فراهم میسازد.
نقش محصولات نشانه در ترکیب SAML و FIDO2
سامانه احراز هویت نشانه بهعنوان یک IdP سازمانی، هر دو استاندارد SAML 2.0 و FIDO2 را بهصورت یکپارچه پشتیبانی میکند. کاربران میتوانند با نشانه توکن (کلید امنیتی USB/NFC مبتنی بر FIDO2)، نشانه موبایل (اپلیکیشن Authenticator روی گوشی هوشمند) یا کارتهای شناسایی NFC در IdP احراز هویت شوند و سپس Assertionهای SAML معتبر برای تمام SPهای متصل صادر شود.
این ترکیب به سازمانها اجازه میدهد بدون تغییر در اپلیکیشنهای SAML موجود خود، صرفاً با ارتقای لایه احراز هویت در IdP به FIDO2، از مزایای احراز هویت بدون رمز عبور و مقاوم در برابر فیشینگ بهرهمند شوند. اپلیکیشنهای SP هیچ تغییری نیاز نداشته و فقط AuthnContextClassRef متفاوتی در Assertion دریافت خواهند کرد.
مدیریت چرخه حیات گواهیها و کلیدهای SAML
یکی از چالشهای عملیاتی مهم در نگهداری زیرساخت SAML، مدیریت گواهیهای دیجیتال X.509 مورد استفاده برای امضا و رمزنگاری خواهد بود. بیتوجهی به این موضوع میتواند باعث قطع ناگهانی سرویس SSO شود.
چرخش گواهیها بدون قطع سرویس
گواهیهای دیجیتال تاریخ انقضا دارند و پیش از رسیدن به آن تاریخ باید جایگزین شوند. فرآیند چرخش گواهی (Certificate Rollover) در SAML شامل مراحل زیر خواهد بود: ابتدا IdP گواهی جدید را تولید و آن را در کنار گواهی قدیمی در متادیتا منتشر میکند (متادیتا میتواند چندین گواهی داشته باشد). سپس SPها متادیتا جدید را دریافت و هر دو گواهی را ذخیره میکنند. پس از اطمینان از بهروزرسانی تمام SPها، IdP شروع به امضای Assertionها با گواهی جدید مینماید. نهایتاً پس از یک دوره انتقالی مناسب، گواهی قدیمی از متادیتا حذف میشود.
نظارت و هشداردهی
سیستم نظارت باید تاریخ انقضای گواهیها را بهصورت خودکار رصد کرده و حداقل ۹۰ روز قبل از انقضا هشدار صادر نماید. عدم تمدید بهموقع گواهیها یکی از شایعترین دلایل قطع سرویس SSO در سازمانها بوده و با یک فرآیند نظارتی ساده قابل پیشگیری خواهد بود.
SAML در معماری Zero Trust
معماری Zero Trust بر اصل «هیچگاه اعتماد نکن، همیشه تأیید کن» استوار است. SAML میتواند نقش مهمی در پیادهسازی این معماری ایفا کند، هرچند محدودیتهایی نیز دارد.
نقاط قوت SAML در Zero Trust
مکانیزم Requested AuthnContext به سازمانها اجازه میدهد سطح احراز هویت مورد نیاز را بر اساس حساسیت هر سرویس تعیین کنند. Attribute Statement امکان انتقال اطلاعات زمینهای (Context) مانند نقش کاربر، مکان جغرافیایی و نوع دستگاه را فراهم کرده و Policy Engine میتواند بر اساس این اطلاعات تصمیمات دسترسی مبتنی بر ریسک اتخاذ نماید.
محدودیتهای SAML در محیطهای مدرن
SAML برای معماریهای مبتنی بر API و Microservices مناسب نیست. Assertionهای XML حجیم برای ارسال در هر درخواست API ناکارآمد بوده و مکانیزمهای SAML برای ارتباطات سرور به سرور طراحی نشدهاند. در این سناریوها، ترکیب SAML (برای SSO وباپلیکیشنها) با OIDC/OAuth (برای حفاظت API) رویکرد عملیتری ارائه میدهد.
چکلیست امنیتی و عملیاتی SAML سازمانی
پیادهسازی موفق و امن SAML SSO نیازمند رعایت مجموعهای از بهترین رویهها در حوزههای مختلف فنی و عملیاتی خواهد بود.
امنیت Assertion و Response
تمام Assertionها باید امضای دیجیتال داشته باشند و SP باید امضا را قبل از هر پردازش دیگری تأیید نماید. شرایط زمانی (NotBefore و NotOnOrAfter) باید با تلرانس حداکثر ۵ دقیقه بررسی شوند تا اختلاف ساعت سرورها مشکل ایجاد نکند اما پنجره حمله Replay نیز محدود بماند. Audience Restriction باید فعال بوده و SP باید تأیید کند که Assertion برای خودش صادر شده است. برای سناریوهای حساس، رمزنگاری Assertion علاوه بر امضا توصیه میشود.
امنیت زیرساخت
تمام Endpointها باید فقط از طریق HTTPS قابل دسترسی باشند. کلیدهای خصوصی مورد استفاده برای امضا باید در HSM (Hardware Security Module) یا حداقل در Keystore رمزنگاریشده نگهداری شوند. لاگهای جامع از تمام رویدادهای SAML شامل AuthnRequest، Response، Assertion Validation و Logout باید ثبت شده و در سیستم SIEM تحلیل شوند.
مدیریت عملیاتی
فرآیند چرخش گواهیها باید مستند و خودکار (تا حد ممکن) باشد. آزمایش دورهای جریانهای SSO و SLO برای اطمینان از عملکرد صحیح ضروری بوده و مستندسازی کامل پیکربندی هر SP شامل EntityID، ACS URL، NameID Format و Attributeهای مورد نیاز باید در یک سیستم مدیریت پیکربندی مرکزی نگهداری شود.
جمعبندی: جایگاه SAML در آینده مدیریت هویت سازمانی
SAML سازمانی پس از بیش از دو دهه همچنان یکی از ارکان اصلی مدیریت هویت و دسترسی در سازمانهای بزرگ باقی مانده است. هرچند پروتکلهای جدیدتری مانند OIDC در حال رشد سریع هستند، واقعیت این است که هزاران اپلیکیشن سازمانی در سراسر دنیا فقط از SAML پشتیبانی میکنند و مهاجرت کامل از SAML به OIDC نه ضروری و نه در بسیاری از موارد عملی خواهد بود.
رویکرد عاقلانه برای سازمانها، استفاده از یک Identity Provider مرکزی است که هم SAML 2.0 و هم OIDC را پشتیبانی کرده و امکان ترکیب آنها با فناوریهای نوین احراز هویت مانند FIDO2 را فراهم سازد. سازمانها میتوانند با ارتقای لایه احراز هویت در IdP خود به FIDO2، بدون تغییر در اپلیکیشنهای SAML موجود، از مزایای احراز هویت بدون رمز عبور بهرهمند شوند.
فدراسیون هویت مبتنی بر SAML همچنان در محیطهای دولتی، آموزشی و بینسازمانی نقش حیاتی ایفا میکند و جایگزین سادهای برای آن وجود ندارد. درک عمیق این پروتکل برای هر متخصص امنیت و IAM ضروری بوده و پیادهسازی صحیح آن میتواند امنیت، بهرهوری و تجربه کاربری سازمان را بهطور چشمگیری ارتقا دهد.
