Single Sign-on (SSO) یک روش احراز هویت است که به کاربران امکان می دهد تا با استفاده از یک مجموعه از اعتبارنامه ها به طور ایمن با چندین برنامه و وب سایت احراز هویت کنند.
SSO بر اساس یک رابطه اعتماد ایجاد شده بین یک برنامه کاربردی که به عنوان ارائه دهنده خدمات شناخته می شود و یک ارائه دهنده هویت مانند OneLogin کار می کند. این رابطه اعتماد اغلب بر اساس گواهی است که بین ارائه دهنده هویت و ارائه دهنده خدمات مبادله می شود. از این گواهی می توان برای امضای اطلاعات هویتی که از ارائه دهنده هویت به ارائه دهنده خدمات ارسال می شود استفاده کرد تا ارائه دهنده سرویس بداند که از منبع قابل اعتمادی می آید. در SSO، این داده‌های هویتی به شکل توکن‌هایی هستند که حاوی بیت‌هایی از اطلاعات مربوط به کاربر مانند آدرس ایمیل کاربر یا نام کاربری هستند.
جریان ورود معمولاً به این صورت است:
1- کاربر برنامه یا وب‌سایتی که می‌خواهد به آن دسترسی داشته باشد، یا همان ارائه‌دهنده خدمات، را باز میکند.
2- ارائه‌دهنده خدمات رمزی را که حاوی اطلاعاتی درباره کاربر است، مانند آدرس ایمیل او، به سیستم SSO، با نام دیگر Identity Provider، به عنوان بخشی از درخواست احراز هویت کاربر ارسال میکند.
3- Identity Provider ابتدا بررسی می کند که آیا کاربر قبلاً احراز هویت شده است یا خیر، در این صورت به کاربر اجازه دسترسی به برنامه Service Provider را می دهد و به مرحله 5 می رود.
4- اگر کاربر وارد سیستم نشده باشد، با ارائه مدارک مورد نیاز توسط Identity Provider از او خواسته می شود که این کار را انجام دهد. این می تواند به سادگی یک نام کاربری و رمز عبور باشد یا ممکن است شامل نوعی دیگر از احراز هویت مانند یک رمز عبور یک بار مصرف (OTP) باشد.
5- هنگامی که Identity Provider اعتبار ارائه شده را تأیید کرد، رمزی را برای تأیید احراز هویت موفق به ارائه دهنده خدمات ارسال می کند.
6- این نشانه از طریق مرورگر کاربر به ارائه دهنده خدمات ارسال می شود.
7- رمزی که توسط ارائه‌دهنده خدمات دریافت می‌شود، بر اساس رابطه اعتمادی که بین ارائه‌دهنده خدمات و ارائه‌دهنده هویت در طول پیکربندی اولیه تنظیم شده است، اعتبارسنجی می‌شود.
8- به کاربر اجازه دسترسی به ارائه دهنده خدمات داده می شود.
هنگامی که کاربر سعی می کند به وب سایت دیگری دسترسی پیدا کند، وب سایت جدید باید یک رابطه اعتماد مشابه با راه حل SSO پیکربندی شده داشته باشد و جریان احراز هویت مراحل مشابهی را دنبال می کند.
توکن SSO مجموعه ای از داده ها یا اطلاعاتی است که در طی فرآیند SSO از یک سیستم به سیستم دیگر منتقل می شود. داده ها می توانند به سادگی آدرس ایمیل کاربر و اطلاعاتی در مورد سیستمی باشد که توکن را ارسال می کند. توکن‌ها باید به‌صورت دیجیتالی امضا شوند تا گیرنده توکن تأیید کند که توکن از یک منبع قابل اعتماد می‌آید. گواهی که برای این امضای دیجیتال استفاده می شود در طی فرآیند پیکربندی اولیه مبادله می شود.
پاسخ به این سوال این است که "بستگی دارد".
دلایل زیادی وجود دارد که چرا SSO می تواند امنیت را بهبود بخشد. یک راه حل ورود به سیستم می تواند مدیریت نام کاربری و رمز عبور را هم برای کاربران و هم برای مدیران ساده کند. کاربران دیگر نیازی به پیگیری مجموعه های مختلف اعتبارنامه ندارند و می توانند به سادگی یک رمز عبور پیچیده تر را به خاطر بسپارند. SSO اغلب کاربران را قادر می سازد تا به برنامه های خود بسیار سریعتر دسترسی پیدا کنند.
SSO همچنین می‌تواند مدت زمانی را که میز کمک برای کمک به کاربران با رمزهای گمشده صرف میکند کاهش دهد. مدیران می توانند الزاماتی مانند پیچیدگی رمز عبور و احراز هویت چند عاملی (MFA) را به صورت متمرکز کنترل کنند. هنگامی که کاربر سازمان را ترک می کند، مدیران همچنین می توانند با سرعت بیشتری از امتیازات ورود به سیستم در سراسر هیئت مدیره صرف نظر کنند.
Single Sign-On دارای اشکالاتی است. برای مثال، ممکن است برنامه هایی داشته باشید که بخواهید کمی بیشتر محدود کنید. به همین دلیل، مهم است که یک راه حل SSO را انتخاب کنید که به شما این امکان را می دهد که مثلاً قبل از ورود کاربر به یک برنامه خاص، به یک فاکتور تأیید هویت اضافی نیاز داشته باشید یا از دسترسی کاربران به برنامه های خاص جلوگیری کند، مگر اینکه به یک برنامه ایمن متصل شوند.
جزئیات نحوه اجرای یک راه حل SSO بسته به اینکه دقیقاً با چه راه حل SSO کار می کنید متفاوت است. اما مهم نیست که مراحل مشخص چیست، باید مطمئن شوید که اهداف روشنی را برای اجرای خود تعیین کرده اید. حتما به سوالات زیر پاسخ دهید:
مهم است که تفاوت بین ورود به سیستم و مدیریت رمز عبور را درک کنید، که گاهی اوقات به آنها SSO می گویند که می تواند به معنای همان Sign-on باشد نه Single Sign-on. با مدیریت گذرواژه، ممکن است نام کاربری و رمز عبور یکسانی داشته باشید، اما هر بار که به برنامه یا وب سایت دیگری منتقل می شوید، باید آنها را وارد کنید. سیستم ذخیره رمز عبور به سادگی اعتبار شما را برای همه برنامه های مختلف ذخیره می کند و در صورت لزوم آنها را درج می کند. هیچ رابطه اعتمادی بین برنامه ها و سیستم ذخیره رمز عبور تنظیم نشده است.
با SSO، به معنای Single Sign-On، پس از ورود از طریق راه حل SSO، می توانید بدون نیاز به ورود مجدد به همه برنامه ها و وب سایت های مورد تایید شرکت دسترسی داشته باشید. این شامل برنامه های کاربردی ابری و همچنین برنامه های کاربردی اولیه است که اغلب از طریق یک پورتال SSO (که پورتال ورود نیز نامیده می شود) در دسترس هستند.
هنگام تحقیق در مورد گزینه های SSO موجود، ممکن است مشاهده کنید که گاهی اوقات به آنها به عنوان نرم افزار SSO در مقابل راه حل SSO در مقابل ارائه دهنده SSO اشاره می شود. در بسیاری از موارد، تفاوت ممکن است صرفاً در نحوه طبقه‌بندی شرکت‌ها باشد. یک نرم افزار چیزی را پیشنهاد می کند که در محل نصب شده است. معمولاً برای انجام یک مجموعه خاص از وظایف طراحی شده است و نه چیز دیگری. یک راه حل نشان می دهد که توانایی گسترش یا سفارشی کردن قابلیت های محصول اصلی وجود دارد. ارائه دهنده راهی برای مراجعه به شرکتی است که راه حل را تولید یا میزبانی می کند. به عنوان مثال، OneLogin به عنوان یک ارائه دهنده راه حل SSO شناخته می شود.
زمانی که در مورد Single Sign-On (SSO) صحبت می کنیم، اصطلاحات زیادی به کار می روند.
SSO در واقع بخشی از یک مفهوم بزرگتر به نام Federated Identity Management است، بنابراین گاهی اوقات SSO به عنوان SSO فدرال شناخته می شود. FIM فقط به رابطه اعتمادی اشاره دارد که بین دو یا چند دامنه یا سیستم مدیریت هویت ایجاد می شود. Single Sign-on اغلب یک ویژگی است که در معماری FIM در دسترس است.
OAuth 2.0 یک چارچوب خاص است که می تواند بخشی از معماری FIM نیز در نظر گرفته شود. OAuth بر روی آن رابطه قابل اعتماد تمرکز می کند که اجازه می دهد اطلاعات هویت کاربر در سراسر دامنه ها به اشتراک گذاشته شود.
OpenID Connect (OIDC) یک لایه احراز هویت است که در بالای OAuth 2.0 برای ارائه عملکرد Single Sign-on ساخته شده است.
Same Sign On که اغلب به آن SSO نیز می گویند، در واقع با Single Sign-on یکسان نیست، زیرا هیچ رابطه اعتمادی بین نهادهایی که احراز هویت را انجام می دهند، ندارد. بیشتر وابسته به این است که اعتبارنامه ها بین سیستم ها تکرار شوند و در صورت لزوم به سادگی در آن اعتبارنامه ها منتقل شوند. به اندازه هیچ یک از راه حل های Single Sign-on ایمن نیست.
همچنین برخی از سیستم‌های خاصی وجود دارند که معمولاً هنگام بحث در مورد Single Sign-on ظاهر می‌شوند: Active Directory، Active Directory Federation Services (ADFS) و Lightweight Directory Access Protocol (LDAP).
Active Directory که امروزه به طور خاص به عنوان Active Directory Directory Services (ADDS) شناخته می شود، سرویس دایرکتوری متمرکز مایکروسافت است. کاربران و منابع برای مدیریت مرکزی به سرویس دایرکتوری اضافه می شوند و ADDS با پروتکل های احراز هویت مانند NTLM و Kerberos کار می کند. بنابراین، کاربرانی که به ADDS تعلق دارند می توانند از دستگاه های خود احراز هویت کنند و به سیستم های دیگری که با ADDS ادغام می شوند دسترسی داشته باشند. این یک شکل از Single Sign-on است.
Active Directory Federation Services (ADFS) نوعی سیستم Federated Identity Management است که قابلیت‌های Single Sign-on را نیز ارائه میکند. از SAML و OIDC پشتیبانی می کند. ADFS در درجه اول برای ایجاد اعتماد بین ADDS و سیستم های دیگر مانند Azure AD یا سایر جنگل های ADDS استفاده می شود.
پروتکل دسترسی به دایرکتوری سبک وزن (LDAP) به سادگی یک استاندارد صنعتی است که راهی برای سازماندهی و جستجوی اطلاعات دایرکتوری تعریف می کند. LDAP به شما امکان می دهد منابعی مانند کاربران و سیستم ها را به صورت متمرکز مدیریت کنید. با این حال، LDAP نحوه ورود شما به آن سیستم ها را تعریف نمی کند، به این معنی که پروتکل های واقعی مورد استفاده در احراز هویت را تعریف نمی کند. با این حال، اغلب به عنوان بخشی از فرآیند احراز هویت و فرآیندهای کنترل دسترسی استفاده می شود. به عنوان مثال، قبل از اینکه کاربر بتواند به یک منبع خاص دسترسی پیدا کند، ممکن است از LDAP برای پرس و جو برای آن کاربر و هر گروهی که به آن تعلق دارند استفاده شود تا ببیند آیا کاربر به آن منبع دسترسی دارد یا خیر. راه حل های LDAP مانند OpenLDAP احراز هویت را از طریق پشتیبانی از پروتکل های احراز هویت مانند احراز هویت ساده و لایه امنیتی (SASL) ارائه می کنند.
همانطور که بسیاری از برنامه های کاربردی دیگر برای اجرا در اینترنت حرکت کرده اند، عملکرد SSO نیز تغییر کرده است. پلتفرم هایی مانند OneLogin که در فضای ابری اجرا می شوند را می توان به عنوان راه حل SSO نرم افزار به عنوان سرویس (SaaS) طبقه بندی کرد.
در نهایت، ممکن است نام App-to-App یا Application-to-Application SSO را شنیده باشید. این هنوز یک استاندارد صنعتی نیست. این بیشتر اصطلاحی است که توسط SAPCloud برای توصیف فرآیند انتقال هویت کاربر از یک برنامه به برنامه دیگر در اکوسیستم آنها استفاده شده است. این تا حدودی شبیه به OAuth 2.0 است اما دوباره یک پروتکل یا روش استاندارد نیست و در حال حاضر مختص SAPCloud است.
