همه آنچه که باید درباره فناوری SAML بدانید

شاید شما هم نام «زبان نشانه گذاری ادعای امنیت (Security Assertion Markup Language)» یا به اختصار SAML را شنیده باشید و احتمالاً حداقل روزی یکبار نیز از آن برای ورود به سامانه های سازمانی تان استفاده کنید. با این حال، آیا می‌دانید SAML چیست، چگونه کار می‌کند و چرا باید با آن آشنا شوید؟

زبان نشانه‌گذاری ادعای امنیت، پروتکل تصدیق هویت در سامانه‌های نرم افزاری تحت وب است که کاربران معمولاً به صورت روزانه از آن برای ورود به سامانه‌ها استفاده می کنند. این زبان باعث آسان‌تر شدن احراز هویت برای کاربران و مدیران سامانه‌ها می‌شود. به عبارت دیگر پروتکل SAML ارتباط امنی را بین سامانه‌ها برقرار کرده و به کاربران امکان می‌دهد تا با یکبار استفاده از نام کاربری و کلمه عبور خود، مجوز دسترسی به سامانه های مختلف را به دست آورند. در این مطلب از فراست، هر آنچه که باید درباره فناوری SAML بدانید را به شما خواهیم گفت.

 

SAML چیست؟

SAML یک استاندارد مبتنی بر زبان نشانه‌گذاری گسترده (Extensible Markup Language) یا XML است که برای برقراری ارتباطات استاندارد، بین ارایه‌دهنده هویت و ارایه‌دهندگان خدمات یا به عبارت دیگر انجام فرایند احراز هویت در برنامه‌های کاربردی تحت وب مثل باکس، مایکروسافت ۳۶۵، سِیلزفورس و جی‌میل از آن استفاده می‌شود.

این پروتکل اقدامات یکپارچه‌سازی، مدیریت هویت و شناسایی یکپارچه (SSO[۱]) را انجام می‌دهد. این کار به معنای آن است که کاربر تنها پس از یکبار احراز هویت و وارد کردن نام کاربری و رمز عبورش، دیگر مجوز ورود به هر سامانه ای که از این استاندارد استفاده می‌کند را خواهد داشت. در واقع یکپارچه‌سازی هویت، امکان ذخیره هویت کاربران در برنامه‌ها و کسب‌وکارهای مختلف را فراهم می کند. با وجود SAML، سامانه‌ها و کسب‌وکارها می‌توانند به کاربران یکدیگر اعتماد کنند.

SAML چه مشکلاتی را برطرف می‌کند؟

معمولاً سامانه‌ها برای حفظ داده‌ها و اعتبارنامه‌های مربوط به حساب‌های کاربری و همچنین ذخیره تمامی داده‌های مورد نیاز برای اعتبارسنجی هویت کاربران، یک پایگاه داده یا پروتکل دسترسی سبک‌وزن راهنما (LDAP[۲]) دارند.

هنگامی که فردی قصد ورود به سامانه را داشته باشد این مخزن، اطلاعات کاربر را بررسی و اعتبارسنجی نموده و سپس آن‌ها را ثبت می‌کند؛ اما وقتی قرار است شخصی وارد چندین سامانه شود که هر کدام از آنها نیازمند اطلاعات هویتی مختلف است، از این جهت که کاربران باید اطلاعات ورود به همه حساب‌های کاربری شان را حفظ کرده و مدیران هم باید این اطلاعات را ثبت و در صورت نیاز لغو کنند، پس ممکن است مشکلاتی ایجاد شود.

فناوری SAML در تلاش برای رفع چنین چالش‌هایی بوده و فرایند احراز هویت برای ورود به وب سایت‌ها و برنامه‌هایی که از SAML پشتیبانی می‌کنند را ساده‌تر کرده است. SAML پرکاربردترین پروتکل برای شناسایی یکپارچه بر مبنای وب محسوب می‌شود. هر سازمان یک صفحه ورود (لاگین) داشته و می‌تواند هر برنامه تحت وب یا ارایه‌دهنده سرویس (SP[۳]) که از پروتکل SAML پشتیبانی می‌کند را انتخاب کند تا کاربران برای ورود به تمام برنامه‌های کاربردی تحت وب آن، تنها به یکبار احراز هویت نیاز داشته باشند (در ادامه بیشتر راجه به این موضوع صحبت می‌کنیم).

اخیراً به دلیل ایجاد یک روش حمله جدید با نام “Golden SAML” که در حادثه امنیتی SolarWinds از آن استفاده شد، پروتکل SAML دوباره خبرساز شده است. این روش، امکان دسترسی به هر سرویس یا دارایی که از استاندارد احراز هویت SAML استفاده می‌کند را به مهاجمان می‌دهد. استفاده گسترده از این روش، اهمیت پیروی از اصول امنیتی را برای مدیریت دسترسی کاربران، بیش از پیش نشان می‌دهد.

به گفته توماس هارجونو، مدیر ارشد فناوری در بخش مهندسی و علوم ارتباطی مؤسسه فناوری ماساچوست و رئیس خدمات امنیتی OASIS بیان کرده که نیاز به وجود استانداردی مثل SAML، در اواخر دهه ۹۰ میلادی و با افزایش تعداد وب سایت‌های تجاری شکل گرفته است. او گفته که هر فروشنده‌ای به دنبال مالکیت فرایند احراز هویت مشتریان خود بود که این امر منجر به ایجاد مشکل برای کاربران گردید چرا که باید نام کاربری و کلمه عبور ده‌ها حساب کاربری مختلف را به خاطر می‌سپردند.

هارجونو می‌گوید: «مشکل کلمه عبور، یک مشکل ۳۰ ساله است. ایده SAML این بود که آیا می‌توان یک موجودیت خاص به نام «ارایه‌دهنده هویت» ایجاد کرد که در واقع موجودیت مجوزدهنده باشد؟».

آشنایی با ارایه‌دهندگان خدمات هویتی

وظیفه یک ارایه‌دهنده خدمات هویتی (IdP[۴])، اعتبارسنجی هویت کاربران و برقراری ارتباط با SP برای ارایه مجوز ورود افراد به سامانه ها است تا بتوانند با کمترین تعداد احراز هویت (لاگین)، به منابع بیشتری دسترسی داشته باشند.

امروزه چندین IdP وجود دارد که بعضی از مهمترین آنها عبارتند از: Okta، OneLogin، Microsoft Active Directory Federation Services، Microsoft Active Directory Federation Services و Ping Identity. وجود SAML برای اعلام این موضوع که IdP کاربر را احراز هویت کرده، ضروری است. هارجونو تعامل بین SP، IdP و کاربر را «یک رابطه یا جریان مثلثی» می‌داند.

SAML چگونه کار می‌کند؟

SAML به SPها یا برنامه‌ها امکان می‌دهد احراز هویت را به یک سرویس اختصاصی یا IdP دیگر محول کنند. SPها به‌ گونه‌ای پیکربندی می‌شوند که در فرایندهای هماهنگی و یکپارچه‌سازی، به IdPهای خاصی اعتماد کنند. برای SP مهم نیست که IdP چگونه هویت کاربر را بررسی و تأیید می‌کند بلکه فقط احراز هویت و تأیید کاربر برای آن اهمیت دارد. از طرف دیگر کاربر نیز فقط به یک نام کاربری و کلمه عبور نیاز دارد که توسط ارایه‌دهنده خدمات هویتی مدیریت می‌شود.

جان مگوایر، مهندس ارشد نرم‌افزار برای تشریح این سازوکار از مثال ورود به کنفرانس تماسی استفاده می‌کند. فرض کنید کارمندی برای ورود به یک جلسه Webex برای شرکت در کنفرانسی ویدیویی، بر روی لینکی کلیک کرده و پس از ورود به صفحه Webex بررسی می‌شود که از چه IdP برای احراز هویت او استفاده شده است (نکته قابل توجه این است که کسب‌وکارها این تنظیمات را از قبل انجام می‌دهند).

سپس Webex کاربر را به IdP خودش هدایت کرده و پیامی حاوی درخواست احراز هویت را برای وی ارسال می‌کند. IdP برای انجام این کار از چند روش می تواند استفاده کند که عبارتند از:

• وضعیت حساب کاربری و اعتبارنامه کاربر را بررسی کند
• دستگاهی که از آن برای دسترسی به برنامه استفاده شده است را بررسی نماید
• شبکه‌ای که کاربر در آن است را بررسی کند

همچنین Webex می‌تواند از احراز هویت چندمرحله‌ای استفاده کند. در این صورت راهبر برنامه، مراحل لازم برای احراز هویت وی را تنظیم می‌کند. مگوایر می‌گوید: «همه این عوامل مشخص می‌کند که اولاً چه سطحی از احراز هویت باید مورد استفاده قرار گیرد؛ از جمله احراز هویت تک عاملی، دوعاملی یا سه عاملی و ثانیاً اینکه آیا اصلاً اجازه احراز هویت را داد یا خیر».

برای مثال اگر IdP متوجه شود امکان شناسایی موقعیت مکانی کاربر وجود ندارد، اجازه احراز هویت را نخواهد داد. IdP این داده‌ها را بررسی کرده و یک پیام به نام «ادعای SAML» تولید می‌کند که هویت کاربر و ویژگی‌های او در آن تأیید شده و برای اثبات اعتبار آنها از الگوریتم‌های رمزنگاری استفاده می‌نماید. سپس این داده‌ها را از طریق فرایند ری‌دایرکت مرورگر (تغییر فرایند آدرس سایت یا تغییر URL آن)، به Webex که امضا را اعتبارسنجی و داده‌های کاربر را بررسی می‌کند، ارسال نموده و در صورت تأیید، مجوز دسترسی کاربر به برنامه مورد نظر را صادر می‌کند.

جیمی پرینگل، مهندس ارشد نرم‌افزار در این خصوص گفته است که: «همه این ارتباطات با استفاده از مرورگر کاربر صورت می‌گیرد. دو طرف هیچ وقت با یکدیگر گفتگو نمی‌کنند». بنابراین معمولاً چندین SP برای یک IdP تنظیم می‌شود. در چنین مواقعی ممکن است کاربر احراز هویت شده، داشبوردی را مشاهده کند که در آن سایر SPهای قابل دسترس برای وی ظرف ۶ ساعت آینده (یا مدتی معین برای حفظ اعتبار نشست) هم مشخص شده‌اند.

احراز هویت مبتنی بر SAML به دو روش امکان پیاده سازی دارد. در فرایندی که توسط SP آغاز می‌شود، کاربر سعی می‌کند به درگاه وب ارایه‌دهنده سرویس وارد شود. به جای درخواست اطلاعات اعتبارنامه، مرورگر همراه با یک درخواست SAML برای احراز هویت، به سمت این IdP هدایت می‌شود. در فرایندی نیز که IdP آن را آغاز کرده باشد، کاربر به IdP وارد و احراز هویت شده، سپس با ادعای SAML به سمت SP هدایت می‌شود. بعضی از SPها روش شروع فرایند توسط SP را پشتیبانی نمی‌کنند و در چنین مواردی تنها می‌توان از روش دوم استفاده نمود.

کسب‌وکارها و مدیران چگونه می‌توانند از SAML استفاده کنند؟

از زمان طراحی و توسعه SAML، این پروتکل تبدیل به استانداردی برای احراز هویت یکپارچه بر مبنای وب شده و توانسته خیلی سریع توجه مشاغل را به خود جلب کرده تا برای احراز هویت کارمندانشان از آن استفاده کنند.

مدیر ارشد تحقیقات در گروه توانمندسازی کسب‌وکار امن مؤسسه گارتنر می‌گوید: «با افزایش اهمیت مدیریت دسترسی، همواره شرکت‌های بیشتری از برنامه‌های در خارج از محیط شبکه خود استفاده می‌کردند. به این ترتیب اهمیت SAML برای سازمان‌ها و کاربرانی که نیاز به احراز هویت یکپارچه داشتند، بیشتر شد».

مزایای این رویکرد برای کاربران و مدیران شبکه‌ها مشخص است. کاربران دیگر نیازی به وارد کردن اطلاعات اعتبارنامه‌های دیجیتال (نام کاربری و کلمه عبور) در برنامه های مختلف ندارند. در مجموع همانطور که ارن پارکی، مدیر ارشد راهبرد امنیت در شرکت Okta گفته، احراز هویت به روشی امن‌تر انجام خواهد شد.

پس از انجام احراز هویت، کاربران می‌توانند در بین سامانه‌های مختلف جا به جا شوند، بدون اینکه نیاز به چندین بار احراز هویت داشته باشند. پارکی همچنین گفته: «این روش از نظر امنیت برای کاربر، کارایی بیشتری دارد؛ چون کاربر، اطلاعات اعتبارنامه دیجیتالی خودش را تنها در سروری که این اطلاعات را دارد یعنی محلی که حساب کاربری او در آن ایجاد شده است، وارد می‌کند. اگر قرار باشد وارد یک برنامه شوید دیگر لازم نیست به آن برنامه اعتماد کنید تا اطلاعات اعتبارنامه شما را مدیریت کند».

به گفته مگوایر، SAML به مدیران امکان می‌دهد تا از یک نقطه دسترسی واحد برای پیاده‌سازی کنترل‌های امنیتی در برنامه‌های مختلف استفاده کنند. بنابراین به جای اینکه نیاز به نگرانی درباره ۲۰ برنامه مختلف و روش‌های احراز هویت آن‌ها داشته باشند می‌توانند IdP را برای بررسی هویت همه کاربران شان تنظیم کنند.

به این ترتیب مدیران می‌توانند سیاست‌هایی مثل احراز هویت چندعاملی را به سرویس‌هایی که از آن‌ها پشتیبانی نمی‌کنند، بیافزایند. همچنین یک نقطه واحد نیز برای بررسی و تحقیق درباره حوادث امنیتی خواهند داشت. با وجود اینکه سادگی و راحتی پیاده‌سازی SAML و امنیت آن هم برای کاربران و هم برای مشاغل اثبات شده است ولی باید به نواقص و معایب آن که با ظهور فناوری‌های جدید برجسته‌تر می‌شوند نیز توجه داشت.

کلی می‌گوید: «این پروتکل نیز معایب خاص خود را دارد؛ از جمله اینکه فاقد امکانات و قابلیت‌های موجود در سایر پروتکل‌های جدیدتر و مدرن‌تر است. با این حال در صورتی که یک برنامه کاربردی تحت وب داشته باشید که به صورت بومی از آن پشتیبانی کند، کار با این پروتکل برای شما آسان بوده و به حفاظت از امنیت سازمان کمک می‌کند».

نکاتی مهم درباره Golden SAML و سولارویندز

شاید در خبرها حادثه امنیتی شرکت سولارویندز که باعث جلب توجه به روش حمله Golden SAML شد و نام پروتکل SAML را شنیده باشید. در این حمله، وقتی کاربری سعی در دسترسی به یک سرویس داشت و درخواست او به سرویس‌های همبسته اکتیو دایرکتوری (Active Directory Federated Services) منتقل می‌شد مهاجم با استفاده از کلید سرقت شده، پاسخ SAML را جعل می‌کرد تا بتواند دسترسی غیرمجاز مدنظرش را به دست آورد.

Golden SAML به مهاجمان امکان می‌دهد به هر برنامه کاربردی که از احراز هویت SAML پشتیبانی می‌کند، دسترسی دایم پیدا کنند. هر چند کارشناسان تأکید دارند این حمله، پروتکل SAML را نقض نکرده اما کلی در این باره می‌گوید:«شاید این حادثه باعث شود سایر مهاجمان به دنبال اجرای حملاتی مشابه، با هدف دستیابی به اطلاعات حساس باشند».

او همچنین گفته: «اگرچه نفوذی به خود SAML صورت نگرفته ولی مهاجمان به اعتبارنامه‌هایی با سطوح دسترسی قابل توجه دسترسی پیدا کرده‌اند. آنها با در اختیار داشتن این اطلاعات توانسته‌اند اعتبارنامه‌های SAML معتبری را صادر کنند. اگر از این دیدگاه به ماجرا نگاه کنیم، در صورتی که سطوح دسترسی را در محیط به خوبی مدیریت نکنید، مهاجمان می‌توانند از این روش استفاده نمایند».

بنابراین نکته مهمی که وجود دارد این است که SAML کاملاً امن است. به گفته هارجونو بسیاری از مشکلات مربوط به SAML در واقع ناشی از پیکربندی نادرست یا سوءاستفاده از این پروتکل هستند. برای مثال ممکن است یک توسعه‌دهنده تازه‌کار فراموش کند قابلیت خاصی را پیاده‌سازی کند یا گروهی که بر روی SAML کار می‌کنند، آن قابلیت را به صورت کامل پیاده‌سازی نکرده باشند.

مگوایر می‌گوید: «سخت‌ترین بخش کار با SAML، پیاده‌سازی آن است. هر برنامه ای که کاربران می‌بایست وارد آن شوند، خواستار اطلاعات کمی متفاوت با سایر برنامه ها است». شاید یک برنامه، نام کاربری یا آدرس ایمیل یا هر دوی آنها را با استفاده از روش‌های نامگذاری مختلف درخواست کند.

یکی از مشکلات SAML این است که حوزه ویژگی‌ها و مشخصات آن بسیار وسیع است و خیلی هم دقیق و مشخص نیست. بنابراین این موضوع می تواند تفاوت‌هایی را در پیاده‌سازی آن ایجاد کند. بعضی از SPها اسناد مبهمی درباره نحوه پیکربندی SAML ارایه‌ می‌کنند که باعث سخت‌تر شدن پیاده‌سازی آن می‌شود.

به گفته پرینگل برای ارسال پیام SAML مناسب باید فیلدهای اطلاعاتی خاصی پر شوند. او می‌گوید: «ما به عنوان یک ارایه‌دهنده سرویس‌های هویتی شاهد هستیم که ارایه‌دهندگان سرویس‌های مختلف برای بعضی از این حوزه‌ها که تعریف دقیقی هم ندارند از تفاسیر متفاوتی استفاده می‌کنند و ممکن است IdPها نیز چنین اشتباهی را مرتکب شوند».

عواقب پیکربندی اشتباه می تواند با توجه به نوع پیاده‌سازی SP متفاوت باشد. ممکن است کاربران از برنامه خارج شوند، امکان احراز هویت آنها وجود نداشته باشد یا پس از ورود، اطلاعات نادرستی را مشاهده کنند. در بعضی از مواقع حتی احتمال دارد دسترسی کاربران، قطع شده و برای رفع مشکل نیاز به تماس با SP داشته باشند.

فناوری جدید، استانداردهای جدید

SAML یکی از اولین استانداردهایی بود که برای حل مشکل احراز هویت مبتنی بر وب طراحی شد و به همین دلیل کاربرد وسیعی نسبت به سایر پروتکل های مشابه دارد. بیشتر سرویس‌های ابری که به کسب‌وکارها فروخته می‌شوند امکان یکپارچه‌سازی آن‌ها با SAML وجود دارد. عموماً IdPها نیز اسنادی از برنامه‌ها که فرایند ادغام و یکپارچه‌سازی قبلاً در آنها صورت گرفته است را دارند.

SAML عضو خانواده‌ای بزرگ از پروتکل‌های احراز هویت مدرن است که استانداردهایی مثل OAuth و Open ID Connect (OIDC) هم در این خانواده قرار دارند. از پروتکل OAuth برای احراز هویت کاربران استفاده شده و به برنامه‌ها امکان می‌دهد از طرف کاربر، اقدامات خاصی را انجام داده یا به منابع ویژه ای دسترسی پیدا کند؛ بدون اینکه نیازی به اعتبارنامه آن‌ها داشته باشد. پروتکل OIDC نیز بر روی OAuth ایجاد شده و یک استاندارد باز است که کسب‌وکارها می توانند از آن برای اعتبارسنجی هویت کاربران استفاده کنند. پارکی این استاندارد را «نسخه مدرن SAML» می‌نامد.

او می‌گوید: «تغییرات اساسی زیادی در دنیای فناوری ایجاد شده که SAML برای مقابله با آن‌ها رشد و توسعه نیافته است». وی برای مثال به “OpenID Connect” اشاره می‌کند که برای کار با گوشی‌های تلفن همراه هوشمند ساخته شده و به جای XML، با JSON طراحی شده است. او معتقد است که: «به نظرم وقتی قرار است از SAML برای فناوری‌های مدرن‌ استفاده کنید، خیلی سریع با محدودیت روبرو می‌شوید».

به گفته پارکی شاید SAML به بحث یکپارچه‌سازی احراز هویت پرداخته باشد اما برای دنیای مبتنی بر API که امروزه در آن زندگی می‌کنیم، طراحی نشده است. برنامه‌های امروزی علاوه بر دانستن هویت کاربر نیاز به دسترسی به API هم دارند که به گفته پارکی، OIDC و OAuth این کار را با بهره‌وری بیشتری انجام می‌دهند.

کلی می‌گوید: «همه کارها با API انجام می‌شود. توسعه‌دهندگان به همین روش کار توسعه را انجام می‌دهند. آن‌ها ترجیح می‌دهند در مسیر توسعه برنامه‌ها از APIها برای احراز هویت استفاده کنند».

به این ترتیب امکانات و عملکرد OAuth و OIDC همواره بیشتر و پیچیده‌تر می‌شود. برای مثال SAML ساده‌تر است اما فاقد قابلیت‌های جانبی پردازش‌های مبتنی بر API است. هر چند کلی اعتقاد دارد پذیرش و استفاده از OAuth و ODIC افزایش پیدا می‌کند اما پیش بینی کرده که پیشی گرفتن آنها از SAML از نظر میزان کاربرد، ۸ الی ۱۰ سال زمان ببرد.

 

[۱] Single Sign-On

[۲] Lightweight Directory Access Protocol

[۳] Service Provider

[۴] Identity Provider