SSO یا Single Sign-On چیست:
به عمل وارد شدن يك كاربر به سايت ها و برنامه هاي مختلف تنها با يك نام كاربري و گذرواژه يكسان SSO يا Single Sign-on(ورود يكپارچه) مي گويند. به اين معني كه اطلاعات مربوط به اعتبار سنجي و تائيد هويت كاربر يعني user name و password ، در يك ناحيه امن به صورت موقت نگهداري مي شود و از آن پس اين كاربر به منظور ورود به سايت های مختلفی که در یک سازمان وجود دارند (و دسترسي به برنامه هاي متعدد) نيازي نيست مجددا Login نمايد. مثلا کاربر با یک بار لاگین بر روی سامانه ی بهشتی دانشگاه می تواند بدون لاگین، صفحات سامانه ی کورس ویر را هم مشاهده کند.
SSO چگونه پیاده سازی می شود:
برای پیاده سازی SSO، عملیات لاگین کلیه سیستم های یک سازمان به عهده ی یک سیستم خاص به اسم Identity Provider (یا همان IdP) گذاشته می شود. بدین معنی که کلیه ی سیستم ها مانند بهشتی، آموزش مجازی و... به یک IdP متصل می شوند و در هنگام انجام عمل لاگین کاربر را به صفحه ای که IdP برای لاگین فراهم می کند هدایت می کنند. بعد از هدایت کاربر به صفحه ی لاگین IdP، کاربر با نام کاربری و پسورد سیستم مورد نظر لاگین می کند، سپس IdP نام کاربر و رمز عبور را در دیتابیس های کلیه ی سیستم های سازمان جستجو می کند و بعد از پیدا کردن نام کاربری و پسورد او آن را Authenticate می کند. سپس کاربر از صفحه ی لاگین IdP به همراه یک توکن(token) (که IdP آن را صادر کرده است و در Cookie مرورگر ذخیره می شود) به صفحه ی سیستم اولیه هدایت می شود. از این به بعد تا زمانی که این توکن معتبر است و زمان آن منقضی نشده است کاربر می تواند بین سیستم های مختلف سازمان بدون نیاز به لاگین مجدد تردد کند زیرا هر یک سیستم های سازمان داشتن این توکن را به عنوان مجوز استفاده از خود می دانند. IdP ها برای صدور توکن و انجام عمل Authentication پروتکل های مختلفی را پشتیبانی می کنند. به عنوان مثال در حال حاضر IdP ها پروتکل های SAML2 و OpenId Connect را برای انجام SSO پشتیبانی می کنند. چند نمونه از IdP های Open Source موجود عبارتند از Apereo CAS Server، WSO2 Identity Server، Keycloak و .... .نکته مهم در اینجا تصمیم در مورد این است که آیا محصول IdP را خودمان پیاده سازی کنیم و یا از محصولات آماده استفاده کنیم.
http://www.tomsitpro.com/articles/single-sign-on-solutions,2-853.html
انواع SSO:
１. Password synchronization (در این حالت سیستم های مخلتف username های مختلف دارند ولی پسورد همه ی آنها یکی است)
２. Enterprise SSO(SSOای که در آن انواع application های یک سازمان از برنامه های وب بیس، برنامه های ویندوزی مانند Desktop application ها یا محصولات Office Microsoft و برنامه های Desktop جاوایی و دیگر برنامه ها از سرویس SSO استفاده می کنند.)
３. trueSSO
４. Web SSO (به SSO بر پایه استاندارد و پروتکل SAML می گویند و فقط application های وب در آن از SSO استفاده می کنند. البته با توجه به پروتکل های جدیدی مثل OpenId Connect ، WebSSO این پروتکل ها را هم در بر می گیرد و فقط مخصوص پروتکل SAML نیست. معمولا برای پیاده سازی بخشی از این نوع SSOوب سایت ها از کوکی استفاده می کنند)
５. Federation(Federated SSO)(cross-organization SSO) : SSO بین کاربران وب اپلیکیشن های دو (یا چند) سازمان مختلف که دو domainاینترنتی مختلف دارند (در این حالت کوکی ساده عمل نمی کند)
http://www.sciencedirect.com/science/article/pii/S2212017312002988
انواع SSO از دیدگاه نحوه ی نگهداری اطلاعات کاربران:
اینکه دو نوع SSO ساده و پیچیده وجود داره SimpleSSO و ComplexSSO در نوع ساده دیتابیس کاربران در یک دیتابیس به صورت متمرکز نگهداری میشه در صورتی که در نوع ComplexSSO دیتابیس کاربران برای هر سیستم به صورت جداست و SSO بین user های این سیستم ها نگاشت برقرار می کند.
Component های SSO از دیدگاه معماری:
1- SSO دارای بخشی به عنوان Access Component است که وظیفه ی کنترل دسترسی کاربران به resource های وب سرور را به عهده دارد. به عنوان مثال، آپاچی شیرو، Access Component است زیرا به عنوان درگاه عمل می کند و دسترسی ها را کنترل می کند.
2- SSO دارای بخشی به نام Identity Component است که وظیفه مدیریت و نگهداری اطلاعات کاربر (مثلا پسورد، گروه، نقش ها، permission ها و غیره) را به عهده دارد. اسم دیگر این واحد Identity Management System(IDM) است. این بخش معمولا در محصولات SSO، به واحد و بخش های ریز تری شکسته می شود به عنوان مثال معمولا بخش مدیریت کاربر(user) و گروه های کاربری (group) را IGA می گویند و بخش مدیریت Role ها و Permission ها را EAC می گویند. IGA مخفف Identity Governance and Administration است و EAC مخفف Entitlements and Access Control است.
3- بخش سوم SSO ، Data Repository نام دارد که معمولا یا یک دیتابیس relational ساده برای نگهداری داده ها کاربران است و یا یک دایرکتوری سرور است که LDAP را ساپورت می کند. بخش Identity management برای نگهداری داده های کاربران از این بخش استفاده می کند. به علاوه Access Component نیز برای کنترل دسترسی و خواندن Role ها و Permission ها از این بخش استفاده می کند.
پروتکل ها و استاندارد های موجود برای پیاده سازی SSO بر اساس token :
برای پیاده سازی SSO به صورت استاندارد و بر مبنای توکن(نه به صورت یک پروتکل شخصی و درون سازمانی) از چهار پروتوکل CAS، SAML، OAuth2 و OpenId Connect می توان استفاده کرد. مفاهیمی که در هر سه پروتکل های SAML و OAuth2 و OpenId Connect مطرح هستند عبارتند از :
1- Service Provider(Resource Server): سایتی (وب اپلیکیشنی) که می خواهیم روی آن لاگین کنیم و لازم است SSO را ساپورت کند مثلا مانند سامانه بهشتی، آموزش مجازی و... Client: مرورگر کاربر.
2- Identity Provider((Authorization Server - IdP: مولفه ای مانند CAS Server که وظیفه ی authenticate کردن کاربر را به عهده دارد و به دیتابیس user/pass کاربران دسترسی دارد.
Service Provider با Identity Provider رابطه ی trust برقرار می کند. و از توکن هایی که identity provider صادر می کند استفاده می کند.
حسن OAuth2 و OpenId Connect نسبت به بقیه ی پروتکل ها در این است که سناریو های sso برای اپلیکیشن های موبایل درآن دیده شده اند. از بین این پروتکل ها، پروتکل OpenId Connect از بقیه جدیدتر است و feature های بیشتری برای ارایه دارد.
پروتوکل های بر مبنای توکن مانندSAML، OAuth2 و OpenId Connect و دیگر پروتکل های از این دست برای Authenticate کردن کاربر و اختصاص توکن به آن Flow دارند. به این معنی که کاربر و مرورگر او طی یک سری مراحل که به Flow معروف است خود را Authenticate می کند و token دریافت می کند.
به عنوان مثال Flow پروتکل OAuth2 در شکل زیر به صورت بسیار خلاصه آورده شده است:
https://www.quora.com/How-does-Google-single-sign-on-work
جستجو در مورد SSO ای که گوگل ارایه می دهد:
گوگل در دو حالت هم به صورت Identity Provider عمل می کند و هم به صورت Identity Provider عمل نمی کند که در زیر شرح داده شده اند:
1- در مورد گوگل، گوگل به عنوان Identity Provider عمل نمی کند بلکه وظیفه ی نگهداری user/pass هایی که سازمان ها دارند به عهده ی خود آنهاست یعنی شرکت های دیگری که از سرویس های گوگل مثل gmail و calendar و غیره استفاده می کنند وظیفه دارند به عنوان Identity Provider عمل کند. در این حین گوگل روی اپلیکیشن های خود SAML-Based Single Sign-on فراهم می کند که شما با لاگین بر روی یک برنامه روی برنامه های دیگر گوگل هم لاگین می شوید. فقط در این عمل Single-Sign-On از اکانتی که شما در شرکت خود دارید استفاده می شود نه اکانت گوگل.
2- گوگل سرویس Google Accounts (یا همان Google Apps) هم دارد که امکان می دهد سایت های شرکت های ثالث عمل authentication خود را توسط اکانت گوگل کاربران انجام دهند در حقیقت در این جا گوگل به عنوان Identity Provider عمل می کند. نوع Identity Provider گوگل از نوع OpenID است. که در حال حاضر گوگل در حال گذار از OpenId و پیاده سازی OpenId Connect است.
http://security.stackexchange.com/questions/37818/why-use-openid-connect-instead-of-plain-oauth
نتیجه جستجو معماری استفاده شده در فیس بوک:
فیس بوک از استاندارد OAuth برای authentication استفاده می کرده است که به دلیل دزدی توکن های صادر شده در پروتکل OAuth که در فیس بوک رخ داد استاندارد به Facebook Connect که نسخه ی کاستومی از OpenId Connect است تغییر یافت.
https://www.ru.nl/publish/pages/769526/z_researchpaper_sso_final_nick_heijmink_s4250559.pdf
http://www.rcgglobalservices.com/blog/the-future-of-single-sign-on-belongs-to-openid-connect
استاندارد OpenID Connectبه عنوان انتخاب برتر:
استاندارد OpenId Connect از سال 2014 مطرح شده است و یک لایه Authentication بر روی پروتکل OAuth2 ایجاد می کند. و از این روش نیز برای برقراری SSO روی وب و موبایل می توان استفاده کرد. بعضی از جنبه های امنیتی OpenId Connect از OAuth2 قوی تر است و تقویت شده است. پیشنهاد خود من بعد از R&D استفاده از OpenId Connect است. در حال حاضر Google ، Twitter ، PayPal، Microsoft و Amazon این استاندارد را پیاده سازی کرده اند و Facebook هم از نسخه ی customize شده ی آن به نام Facebook connect استفاده می کند.
با توجه به جستجو های انجام شده و مقالات موجود OpenId Connect تکنولوژی بعدی بعد از SAML خواهد بود و SAML را در زمینه SSO پشت سر می گذارد.
دلایل زیر به صورت خلاصه از منابع مختلف جمع آوری شده اند که علت برتری OpenId Connect نسبت به دیگر پروتکل ها را بیان می کنند :
ü (مقایسه OpenId Connect با OAuth2) مزیت OpenId Connect نسبت به OAuth2 این است که OpenId Connection بر خلاف OAuth2 که برای Authorization استفاده می شود ، Authentication را هم پشتیبانی می کند.
ü (مقایسه OpenId Connect با SAML) هر دوی SAML و OpenId Connect ، Authentication و Authorization را پشتیبانی می کنند ولی بر خلاف SAML که تنها سیستم های web-base را پشتیبانی می کند، OpenId Connect برنامه های native(به معنی Desktop) و mobile را هم پشتیبانی می کند. به علاوه بر خلاف SAML که بر پایه XML است و هزینه پارس آن را به همراه دارد OpenId Connect بر پایه JSON و تکنولوژی REST است. از لحاظ نحوه ی encryption و decryption هر دوی پروتکل ها با هم تفاوت هایی دارند که در اینجا به صورت بسیار مختصر به آن اشاره می کنیم. SAML برای پایه message-level-security بنا نهاده شده به این معنی که بدنه مسیج SOAP رمز گلستانی می شود و بر روی کانال (احیانا کانال غیر امن) ارسال می شود ولی در OpenId Connect استفاده از message-level-security اختیاری است یعنی بدنه مسیج JSON رمزگلستانی نمی شود ولی کانالی که مسیج روی آن می رود باید امن شده باشد(مثلا کانال باید با پروتکل TLS امن شده باشد). به عنوان تفاوت آخر SAML در زمینه رجیستر کردن web-application هایی که مجاز به استفاده از آن هستند (مثلا بهشتی و گلستان) رفتار استاتیک دارد به این معنی که این رجیستریشن در زمان اجرا قابل تغییر و به روز رسانی نیست ولی پروتکل OpenId Connect رفتار پویا دارد و می توان کلاینت های جدید را در زمان اجرا رجیستر کرد.
ü (مقایسه OpenId Connect با CAS) از CAS زمانی استفاده می شود که بخواهیم SSO را برای کاربران یک سازمان پیاده سازی کنیم، مثلا برای دانشگاه بهشتی، ولی از OpenId Connect می توان برای Federated SSO هم استفاده کرد به این معنی که سرویس SSO را بین کاربران چند سازمان ایجاد کنیم. به علاوه CAS تنها Authentication را پشتیبانی می کند و Authorization را پشتیبانی نمی کند. به علاوه CAS پروفایل کاربر را بعد از لاگین در اختیار قرار نمی دهد ولی OpenId Connect این پروفایل را در اختیار می گذارد.
ü (دلایل دیگر استفاده از OpenId Connect) در OpenId Connect سعی شده است بار و پیچیدگی پیاده سازی از سمت RP ها به سمت OP ها منتقل شود در صورتی که در پروتکل های قبلی مانند SAML پیچیدگی پیاده سازی بین کلاینت و سرور تقریبا یکسان است.
ü (دلایل دیگر استفاده از OpenId Connect) پشتیبانی از application های موبایل
ü (دلایل دیگر استفاده از OpenId Connect) جدیدترین استاندارد است که کمپانی های بزرگ پیاده سازی کرده اند و برمبنای استاندارد های جدید وب است
ü (دلایل دیگر استفاده از OpenId Connect) هر دو مفهوم Authentication و Authorization را پشتیبانی می کند و رشد سریعی دارد
ü دلایل فوق از تز "Secure Single Sign-On A Comparison of protocols" نوشته ی Nick Heijmink استخراج شده اند که در تاریخ 27 جولای 2015 به انتشار رسیده است.
ü CAS Server از OpenId Connect پشتیبانی می کند به علاوه برای آپاچی شیرو لایبراری به نام pac4j موجود است که امکان استفاده OpenId Connect در شیرو را فراهم می آورد.
گوگل برای استاندارد OpenId Connect بر روی گوشی های اندروید لایبراری AppAuth را ارایه داده است. به زبان دیگر گوگل در حال ارایه لایبراری برای استفاده از این استاندارد است. در زیر flow این استاندارد نمایش داده شده است که مشابه فلو OAuth2 مولفه های Idp و Client حضور دارند:
http://connect2id.com/learn/openid-connect
شرح استاندارد OpenId Connect(OIDC):
در شکل زیر نمای کلی پروتکل OpenId Connect نمایش داده شده است:
Spec ها و بخش های مختلف OpenId Connect با توجه به نمودار بالا وضع و پیاده سازی شده اند. سه بخش Core، Discovery و Dynamic Client Registration از بخش های اصلی OPIC هستند که شرح آنها قبل از معرفی المان های اصلی این پروتکل که در زیر آمده است امکان پذیر نیست.
پروتوکل های بر مبنای توکن مانندSAML، OAuth2 و OpenId Connect و دیگر پروتکل های از این دست برای Authenticate کردن کاربر و اختصاص توکن به آن Flow دارند. به این معنی که کاربر و مرورگر او طی یک سری مراحل که به Flow معروف است خود را Authenticate می کند و token دریافت می کند(در بعضی Flow ها مرورگر دخیل نیست و مستقیما توکن دریافت می شود). در پروتکل OpenId Connect سه flow وجود دارد که هریک در زمان خاص خود مورد استفاده میگیرند اما از بین این سه flow ، یک flow اصلی وجود دارد که به Authorisation code flow معروف است.این flow بیش از دو flow دیگر مورد استفاده قرار می گیرد. این فلو همان سناریو و روال معمول لاگین بر روی سایت توسط مرورگر را توضیح می دهد. به علاوه پروتکل OAuth2 نیز Flow ای به نام Resource Owner & Password Credentials flow دارد. این فلو شرح می دهد چگونه می توان با نام کاربری و رمز عبور یک token معتبر دریافت کرد و به سرویس های REST ای که perotected هستند دسترسی داشت. دقت کنید که به دلیل اینکه پروتکل OpenId Connect بر روی پروتکل OAuth2 ساخته شده است فلو های پروتکل OAuth2 نیز در این پروتکل وجود دارند و پشتیبانی می شوند. در حال حاضر کاربرد های دانشگاه بهشتی محدود به این دو flow است. یعنی یا ما می خواهیم با کمک مرورگر بر روی سامانه SSOLogin انجام دهیم و یا می خواهیم سرویس های REST خود را با نام کاربری و رمز عبور و توکن Secure کنیم. ابتدا فلو Authorisation code flow را شرح می دهیم. فقط قبل از شرح این flow مفاهیم و کلمات کلیدی را مطرح می کنیم که در این استاندارد با آن سرو کار داریم. در بالا در قسمت پروتکل های token base قبلا این مفاهیم را تعریف کردیم فقط در اینجا آنها را با اسامی جدید باز تعریف می کنیم که این اسامی خاص استاندارد OpenId Connect است:
1- Relying Party (Service Provider): منظور سامانه ایست (وب سایت ایست) که وظیفه ی Authentication خود را به عهده ی سرویس SSO می گذارد. بدین معنی که ما سرویس SSO را بر روی یک سرور راه اندازی می کنیم (مثلا CAS Server) و از آن به بعد وب سایت ما به جای این که عملیات لاگین را خود به عهده بگیرد این کار را به عهده ی سرویس SSO می گذارد یعنی کاربر را به جای این که به صفحه ی لاگین خودش هدایت کند به صفحه لاگین SSO هدایت می کند. مثلا در صورتی که سیستم های بهشتی و گلستان از SSO استفاده کنند به آنها Relying Party ( یا به اختصار RP ) می گوییم.
2- OpenId Provider (Identity Provider) : سرویس SSO مرکزی. این سامانه در حقیقت دیتابیس ای از کاربران و پسورد آنها را در اختیار دارد و درخواست Authentication را از Relying Party ها دریافت و کاربر را Authentication می کند و توکن صادر شده را به آنها بر می گرداند. به عنوان مثال CAS Server یک OpenId Provider است. به OpenId Provider به اختصار OP یا در ادبیات دیگر IdP می گویند.
3- Client: مرورگر کاربر.
در ادامه به Relying Party ، RP و به OpenId Provider ، OP می گوییم.
Authorisation code flow:
در Authorisation code flow که در بالا به آن اشاره شد فرایند لاگین کاربر بر روی SSO مشتمل بر دو گام است که طی آن یک Identity Token (یا با نام دیگر ID Token) از طرف OP برای RP صادر می شود. نکته جالب این است که این توکن تحویل مرورگر نمی شود و مستقیما بین OP و RP رد و بدل می گردد.
دو گامی که در بالا به آنها اشاره شد در پایین توضیح داده خواهند شد. خلاصه این دو گام و نتایج هر مرحله به صورت جدول زیر نمایش داده شده اند:
به صورت خلاصه در گام اول کاربر به صفحه ی لاگین OP هدایت شده و لاگین می کند و یک کد به اسم Auhtorisation Code تولید می شود که با redirect شدن مرورگر به صفحه ی مشخص شده ی RP به دست RP می رسد. در ادامه و در مرحله دوم RP این کد را از طریق یک ارتباط مستقیم امن به دست OP می رساند و از OP ، ID Token دریافت می کند.
در ادامه مراحل را به تفصیل توضیح می دهیم.
گام اول:
RP برای Authenticate کردن کاربر جدیدالورود ابتدا کاربر را به authorization endpoint ای که OP دارد redirect می کند(به صفحه ی لاگین OP کاربر را redirect می کند). این درخواست احراز هویت در واقع چیزی نیست جز یک OAuth2 authorisation request معمولی که در این درخواست دسترسی به نام کاربری کاربر درخواست شده است. به عبارت دیگر یک درخواست دسترسی به نام کابری کاربر از طرف RP برای OP ارسال می شود. یک نمونه این درخواست در زیر آمده است که کاربر جدید الورود به آدرس htts://opened.c2id.com/login (که همان authorization endpoint است) هدایت می شود:
پارامتر های این request در ذیل آمده است شرح داده شده اند:
1- Response type: مقدار این پارامتر به code ست شده است که بیانگر نوع flow است که در اینجا
Authorization code flow منظور نظر ماست.
2- Scope: برای دریافت ID Token و انجام عملیات authentication مقدار این فیلد باید به openid ست شود.
3- Client_id: شناسه ی RP است که در نزد OP ثبت شده است. یعنی شناسه ی یکتای سامانه ای که از سرویس SSO می خواهد استفاده کند را نشان می دهد. مثلا ممکن است شناسه 12assd09 به سامانه بهشتی اختصاص داده شود.
4- State: شناسه ایست که RP به این درخواست نسبت می دهد تا بعدا بعد از لاگین شدن بر روی OP و انجام redirect از OP به RP این شناسه به RP برگردانده شود تا RP متوجه شود لاگین کدام request موفقیت آمیز بود.
5- Redirect_uri: آدرسی که باید OP بعد از نمایش صفحه ی لاگین و انجام لاگین کاربر باید آن را برای ارسال authorization code تولید شده (خروجی گام یک) صدا کند.
بعد از redirect شدن کاربر، کاربر بر روی صفحه ی لاگین OP (شکل زیر) لاگین می کند:
بعد از اینکه OP صفحه ی لاگین را به کاربر نشان داد و کاربر بروی آن لاگین کرد، OP آدرس redirect_uri که در بالا به آن اشاره شد را به همراه authorization code تولید شده (خروجی گام 1) فراخوانی می کند.
در حین فراخوانی request بالا RP باید مقدار پارامتر state را اعتبارسنجی کند و از پارامتر code که همان authorisation code ایست که OP برای RP تولید کرده است برای رفتن به گام دوم استفاده کند.
گام دوم:
در گام دوم RP ، authorization code تولید شده در گام 1 را برای OP ارسال می کند و ID Token دریافت می کند. برای انجام این عمل RP درخواستش را به token endpoint ای که OP در اختیار می گذارد می فرستد. نمونه این درخواست در ذیل آمده است:
بخش های مخلتف request فوق در ذیل شرح داده شده اند:
1- در هدر Authorization، client_id مرحله یک و پسورد RP نزد OP ست می شود.
2- مقدار پارامتر grant_type به authorization_code ست می شود.
3- مقدار redirect_uri هم همان مقدار redirect_uri گام 1 را دارد.
در پاسخ به این درخواست OP یک JSON که حاوی ID Token است بر می گرداند که نمونه آن در زیر آمده است:
Resource Owner & Password Credentials flow
در این flow هدف فراخوانی یک سرویس REST است که توسط OP محافظت می شود. در حقیقت یکی از سرویس هایی که OP ها فراهم می کنند محافظت کردن از سرویس های RESTFul ایست که ما develop می کنیم. به این معنی که شما برای فراخوانی متد های این سرویس ها باید در هدر request، توکن معتبری که از OP درخواست کرده اید را قرار دهید تا بتوانید سرویس REST را با موفقیت فراخوانی کنید. برای دریافت این توکن که به وسیله آن بتوان سرویس REST را فراخوانی کرد، OP یک Flow به نام Resource Owner & Password Credentials flow دارد. به صورت ساده برای انجام این flow کافی است یک درخواست همراه با username و password کاربر مجاز به درگاه خاصی که OP فراهم می کند و به token endpoint معروف است ارسال می کنیم. در پاسخ OP یک توکن به ما بر می گرداند که از آن می توانیم برای فراخوانی سرویس REST مد نظرمان از آن استفاده کنیم.
در تست های جاری اینجانب به دلیل اینکه مجبور شدم از این flow هم استفاده کنم لازم دیدم که این Flow را هم در اینجا شرح دهم.
به عنوان یک مثال برای فراخوانی سرویس های Admin RST API ای که KeyCloak دارد باید از flow فوق استفاده شود و بدون داشتن token معتبر نمی توان این سرویس را استفاده کرد.
http://wiki.openid.net/w/page/12995200/OpenID%20Security%20Best%20Practices
Best practice هایی که در هنگام استفاده از OpenId Connect باید در نظر گرفت:
ü Best practice هایی که برای کاربرانی که با OpenId Connect لاگین می کنند باید رعایت شوند:
1- به دلیل استفاده از SSO باید پسورد کاربر که همزمان چندین سایت را حفاظت می کند قوی باشد.
2- کاربر باید در برابر Phishing حساس و آگاه باشد زیرا صفحه ی لاگین ای که OP نمایش می دهد ممکن است صفحه ی جعلی باشد بنابراین URL صفحه ی لاگین همواره باید توسط کاربر چک شود که به مکان درستی اشاره کند.
3 - کاربر باید همواره بعد از استفاده از RP، Logout کند و مرورگر را به صورت باز رها نکند.
ü Best practice هایی که برای RP ها باید اعمال شوند:
1- Relying Party ها باید در برابر حملات XSS و XSRF تجهیز شده باشند.
2- به جای پیاده سازی پروتکل OpenId Connect به صورت from scratch باید RP ها از لایبراری های موجود در این زمینه استفاده کنند.
3- RP ها باید بعد از لاگین سشن ای برای کاربر درست کنند که با سشن ای که OP برای کاربر درست کرده است همزمان باشد یعنی نباید این سشن طولانی تر از سشن کاربر در OP باشد. بدین منظور RP ها باید مرتبا endpoint های OP برای چک فعال بودن سشن کاربر را فراخوانی کند تا در صورت پایان سشن، سشن RP هم بسته شود و کاربر از RP اخراج شود.
ü Best practice هایی که برای OP ها باید اعمال شوند:
1- صفحه ی لاگین ای که OP فراهم می کند همواره باید بر روی SSL باشد. و موارد تکنیکال دیگر که بیان آنها در این نوشته نمی گنجد.
محصولات SSO یا همان IdP(Identity Provider) هایی که موجود هستند:
در حال حاضر محصولات SSO به دو دسته ی سرویس دهنده های SSO و پروداکت های SSO تقسیم می شوند. سرویس دهنده ی SSO شرکتی است که شما از آن سرویس SSO را خریداری می کنید. ولی پروداکت SSO به معنی محصولات هستند که در زمینه ی SSO موجود هستند مانند CAS Server کاممیونیتی Apereo. آنچه بیشتر در حال حاضر فراوانی و نمود دارد سرویس دهنده های SSO هستند که پروتکل هایی مانند SAML ، OAuth2 و OpenId Connect را در اختیار می گذارند. نمونه هایی از این سرویس دهنده ها عبارتند از Okta، OneLogin، Stormpath و ... . این سرویس دهنده ها به صورت آنلاین عمل می کنند بدین معنی که شما مجبور هستید نام کاربری و رمز عبور کاربران خودتان را در این دیتابیس آنها ذخیره کنید. در واقع شما سرویس SSO را از این سرویس دهنده ها خریداری می کنید نه محصولات SSO را. برای مشاهده مقایسه بین امکانات این سرویس دهنده ها می توانید به مقاله زیر :
http://www.pcmag.com/article2/0,2817,2491437,00.asp مراجعه کنید.
محصولاتی(و نه سرویس) OpenSource ای هم در زمینه SSO وجود دارند که در زیر بعضی از آنها لیست شده اند(به این محصولات به صورت کلی IdP یا همان Identity Provider گفته می شود):
ü Apereo CAS Server
ü OpenAM: https://forgerock.org/openam/
ü WSO2 Identity Server : http://wso2.com/products/identity-server/
ü Shibboleth Identity Provider
ü Gluu Server Community Edition
ü JOSSO Community Edition
ü IdentityServer4 مایکروسافت
ü mitreid-connect
ü Keycloak
نمونه ای از چند محصولات ClosedSource که وجود دارند:
ü Connect2id server
معمولا در نرم افزار های تجاری، هر سیستم، دیتابیس user/pass خود را دارد و role/permission ها را به صورت جداگانه نگهداری می کند. ایده استفاده از IdP به این شکل است که با معرفی این دیتابیس های جزیره ای در دانشگاه به IdP، امکان لاگین بر روی همه ی این دیتابیس ها فراهم می شود. یعنی وقتی کاربر در صفحه ی لاگین دکمه ی ورود را می زند IdP نام کاربری را بر روی همه ی این دیتابیس ها جستجو کرده و در صورت یافتن نام کاربری ، کاربر را Authenticate می کند. در معماری دیگری IdP نیز برای خود یک یک دیتابیس مرکزی دارد که کلیه ی نام کاربری ها و پسورد ها را از دیتابیس های دیگر import می کند و امکان SSO را فراهم می آورد. به عنوان مثال WSO2 امکان معرفی دیتابیس های جانبی را دارد و KeyCloak برای خود دیتابیس مرکزی دارد. برای استفاده از IdP باید کاربر را در هنگام لاگین به صفحه ی لاگین IdP هدایت نمود.
http://wso2.com/products/identity-server/#Features
به عنوان یک نمونه از اینکه یک IdP تا چه حد می تواند امکانات جامعی را در اختیار قرار دهد، در ذیل امکانات WSO2 را به صورت دسته بندی و خلاصه شده شرح می دهیم که نمونه ایست از امکاناتی که یک محصول SSO می تواند ارایه دهد:
دسته اول ، امکانات خاص SSO(انواع پروتکل های SSO که ساپورت می شود):
1- انجام SSO از طریق پروتکل های SAML2 و OpenId Connect
2- مدیریت Session برای پروتکل OpenId Connect
3- Federated SSO از طریق پروتکل های SAML2 و OpenId Connect
4- Enterprise SSO برای برنامه هایی چون Microsoft Office 365، Microsoft Sharepoint، Microsoft Dynamics و Microsoft Exchange
دسته دوم، امکانات خاص انجام عمل Authentication – به مجموعه این ویژگی ها در ادبیات SSO ، Strong Authentication گفته می شود:
1- پشتیبانی از Authentication چند مرحله ای
2- پشتیبانی از Windows Authentication
3- پشتیبانی از X509 Authentication
4- و روش های پیشرفته دیگر Authentication مثل 2-Factor Authentication
دسته سوم، امکانات مدیریت کاربران (نام کاربری و پسورد آنها) – بخش IGA که قبلا معرفی شد:
1- پشتیبانی از user ها و group ها(گروه های کاربری)
2- پشتیبانی از Claim ها (Claim در واقع چیزی نیست جز یک فقره اطلاع در مورد کاربر مثلا ایمیل کاربر) با استفاده از Claim می توان داده ها و attribute های مورد نظر برای یک کاربر را ذخیره کرد
3- پشتیبانی از Profile کاربر، هر کاربر می تواند چند پروفایل داشته باشد
4- امکان ایجاد ارتباط بین یک دو سه و یا چند حساب کاربری که همه متعلق به یک کاربر هستند
5- امکان ذخیره کاربران در انواع مدیا ها مثل RDBMS ها و LDAP Server ها
6- امکان تنظیم پسورد پالیسی
7- امکان لاک کردن کاربر در صورت تلاش های مکرر ناموفق برای لاگین
8- امکان بازیابی حساب کاربر(reset کردن پسورد) با سوالات امنیتی و ایمیل کاربر
9- امکان تعریف User Store که توسط آن می توان دیتابیس های کاربران که در سیستم های توسعه داده شده دانشگاه مثل بهشتی و گلستان را به عنوان دیتابیس ای که کاربران باید از آن خوانده شوند معرفی کرد
دسته چهارم، امکانات مربوط به Authorization مثل role ها و permission های کاربر – بخش EAC که قبلا معرفی شد:
1- امکان تعریف Role برای کاربران (پشتیبانی از RBAC)
2- امکانات کنترل سطح دسترسی ریز دانه بر اساس پروتکل XACML
دسته پنجم، امکانات Monitoring سرور:
1- ثبت رویداد login کاربر و مانیتور کردن session او
2- امکانات manage و monitoring سرور با استفاده از MBean های JMX
در زیر نمایی از کنسول مدیریتی WSO2 نمایش داده شده است:
در شکل امکانات مدیریت کاربران و نقش ها و امکان تعریف Service Provider (مثلا بهشتی یا گلستان) و تعریف Identity Provider های دیگر که برای federated sso به کار می رود وجود دارد.
در مقایسه واسط کاربری CAS Server ساده است و قابلیت های چندانی را ارایه نمی دهد. نمای کلی آن در زیر آمده است:
واسط کاربری KeyCloak هم در زیر نمایش داده شده است که نسبت به واسط های کاربری بقیه ی IdP ها قوی تر است:
مقایسه بین محصولات SSO موجود (IdP های موجود):
برای مقایسه بین محصولات SSO موجود گزارش جامعی که محصولات SSO را مقایسه کرده باشد موجود است اما پولی است:
https://www.gartner.com/doc/3084928/opensource-options-identity-access-management
مقالات پراکنده راجع به مقایسه دوبدوی محصولات SSO وجود دارد و مقایسه های موجودی که تا کنون پیدا شده اند عبارتند از:
مقایسه بین OpenAM و WSO2
مقایسه بین OpenAM و Gluu
https://www.gluu.org/blog/the-gluu-server-vs-openam-opensso/
مقایسه ای بین KeyCloak و WSO2
http://lists.jboss.org/pipermail/keycloak-user/2016-August/007281.html
معیار مهم برای انتخاب محصول SSO باید داکیومنتیشن های موجود برای محصول باشد زیرا بدون مستندات موجود پیکربندی محصولات SSO امکان پذیر نیست زیرا اکثر این محصولات حول مفاهیم Security پیاده سازی شده اند و بدون مستندات کافی کار با این محصولات بسیار دشوار است.
WSO2 پروتکل هایی که ساپورت می کند:
WSO2 واسط کاربری دارد که نقطه ی قوت آن محسوب می شود ولی مشکلی که فعلا در مورد آن وجود دارد این است که WSO2 پشتیبانی کاملی از پروتوکل OpenId Connect ندارد برای مثال discovery endpoint پروتکل OpenId Connect در WSO2 وجود ندارد و در نسخه های آینده اضافه خواهد شد. وجود این endpoint برای راه اندازی pac4j و شیرو برای استفاده از WSO2 ضروری است که فعلا این امکان وجود ندارد. یکی از امکانات WSO2 که به نظر جالب می آید امکان افزودن چند User Store به سیستم است. به این معنی که هر دیتابیس user/pass ای که موجود است مثلا دیتابیس گلستان و بهشتی را به صورت یک user store به WSO2 اضافه می کنیم. در این حالت به هر یک از user store ها یک نام منطقی منتسب می کنیم که کاربر در هنگام لاگین باید نام کاربری و آن نام منطقی را در کنار هم وارد کند مثلا golestan/user1 یا beheshti/user1. البته برای تست این امکان WSO2 نصف روز زمان صرف شد ولی با موفقیت تست نشد. وجود این امکان باعث می شود بتوان username هایی که در دو سیستم مثلا گلستان و بهشتی مشابه هستند (مثلا نام کاربری user1 در هر دو سیستم وجود دارد) را از هم تمیز داد و در سیستم WSO2 وارد (import) کرد.
یکی از نقاط ضعف wso2 این است که مفهوم Realm را در واسط کاربری اش پشتیبانی نمی کند و این بدین معنی است که نمی توان دسته بندی از user/role/permission/application تحت عنوان یک Realm ایجاد کرد. در صورتی که KeyCloak چنین ویژگی ای را پشتیبانی می کند.
یکی از نقاط ضعف WSO2 عدم امکان ایجاد role تحت زیر مجموعه یک سیستم است یعنی مثلا نمی توان تحت سیستم گلستان role تعریف کرد. در صورتی که بخواهید چنین کاری بکنید باید این نقش را به یک نقش Global در WSO2 نگاشت شود. در صورتی که در KeyCloak چنین الزامی وجود ندارد و role ها بدون نیاز به هیچ نگاشتی تحت یک سیستم تعریف می شوند.
یکی از امکاناتی که WSO2 ارایه می دهد امکان مدیریت کاربران/نقش ها و موارد از این دست از طریق چند وب سرویس است مثلا آدرس wsdl وب سرویس مدیریت کاربران در زیر آمده است:
https://localhost:9443/services/UserAdmin?wsdl
WSO2، Federated Login را پشتیبانی می کند. برخی از IdP های معروفی که WSO2 با آنها integerate می شوند عبارتند از :
Facebook, Microsoft, Google, Twitter, Yahoo, “Every IdP which supports SAML2 and OpenId Connect”
KeyCloak
پروتکل هایی که ساپورت می کند:
KeyCloak محصولی از JBoss است که اخیرا توسعه داده شده است و OpenId Connect را پشتیبانی می کند. واسط کاربری نسبتا راحتی برای کار دارد و امکانی به نام User Federation را ارایه می دهد که دیتابیس های مختلف که حاوی user/pass هستند را می توان به آن معرفی کرد تا برای authentication از آنها استفاده کند(که این ویژگی برای بهشتی و گلستان که هر یک دیتابیس های user/pass جداگانه ای دارند به نظر مناسب است). اما متاسفانه در مورد integrate کردن آن با آپاچی شیرو با استفاده از لایبراری pac4j مشکلاتی وجود دارد. مثلا Logout به درستی کار نمی کند. که این مورد در پست زیر اشاره شده است که pac4j و KeyClaok با یکدیگر به درستی کار نمی کنند. در حال حاضر KeyCloak ، Adapter ای برای Spring Security فراهم آورده است که با استفاده از آن می توان در برنامه های Spring MVC به صورت آماده به SSO دست یافت(تحت پروتکل OpenId Connect). سمپل آن تست شده است و به درستی کار می کند.
یکی از ویژگی های جالبی که KeyCloak ارایه می دهدSPI User Federation است به این معنی که می توان دیتابیس های موجود user/pass را به KeyCloak معرفی کرد تا لیست کاربران و رمز عبور آنها را از آنجا لود کند و عمل Authentication را روی این دیتابیس ها انجام دهد. محدودیت این روش این است که تنها عمل Authentication به این شکل قابل سفارشی سازی است و برای Role ها و Permission ها و عمل Authorization چنین امکانی در حال حاضر وجود ندارد. یعنی نمی توان KeyCloak را وادار کرد اطلاعات مربوط به role ها و permission ها را از دیتابیس مورد نظر ما لود کند. البته در صورتی که از KeyCloak فقط برای Single Sign On استفاده شود این روش کافی است ولی در صورتی که بخواهید از KeyCloak برای Authorization استفاده نمایید این روش سودمند نیست.
یکی از محدودیت هایی که KeyCloak به نظر در زمینه import کردن کاربران از دیتابیس های دیگر دارد این است که مثلا اگر دو دیتابیس گلستان و بهشتی را به KeyCloak وصل کنیم ، username هایی که بین این دو سیستم یکی هستند باید با روشی برای KeyClaok قابل تمیز باشند یعنی مثلا اگر کاربر johnsmith در هر دو سیستم وجود دارد باید با روشی این نام کاربری را یکتا کرد مثلا با افزودن دامنه به انتهای آن. مثلا johnsmith@golestan و johnsmith@beheshti که در این روش نام کاربری ها در دیتابیس مرکزی KeyCloak به گونه ای متفاوت از گلستان و بهشتی ذخیره خواهند شد. در صورتی که مثلا در مورد WSO2 این امکان به صورت built-in در آن وجود دارد.
یکی از امکاناتی که KeyCloak ارایه می دهد ، داشتن API مدیریتی به صورت سرویس REST است یعنی امکاناتی که KeyCloak از طریق واسط کاربری تحت وب خود ارایه می دهد مثل مدیریت Realm ها، user ها ، role ها و ... را می توان با فراخوانی این API به دست آورد. این امکان کمک می کند برنامه های استفاده کننده سرویس SSO مثل گلستان و بهشتی بتوانند داده های امنیتی خود را با سیستم مرکزی SSO ، همگام کنند(با فراخوانی این سرویس).
یکی از نقاط قوت KeyCloak مدل Permission آن است که بسیار قدرتمند است. توسط آن در حالت کلی می توان سناریو های دانشگاه بهشتی که مطابق الگوی توصیف شده در عکس زیر هستند را کاملا پوشش داد. به دلیل قدرتمند بودن توضیحات انگلیسی خود متن انگلیسی از سایت KeyCloak آورده شده است. Permission در KeyCloak عبارت است از :
برای مطالعه بیشتر در مورد مدل Permission های KeyCloak با آدرس زیر مراجعه کنید:
امکان دیگری که KeyCloak ارایه می دهد در اختیار قرار دادن page است که هر کاربری که در سیستم ها ما مثل بهشتی و گلستان وجود دارد می تواند روی این page لاگین کند و Account خود را مدیریت کند. مثلا پسورد خود را عوض کند. آین صفحه در آدرس زیر در دسترس است:
http://localhost:8080/auth/realms/{realm_name}/account/
ویژگی دیگر KeyCloak علاوه بر پشتیبانی Role-Based Authorization ، پشتیبانی از Rule-Based Authorization و Drool است.
KeyCloak ویژگی Federated Login را پشتیبانی می کند. بعضی از IdP های معروفی که KeyCloak پشتیبانی می کند عبارتند از :
GitHub, Twitter, Facebook, Google, LinkedIn, Microsoft, StackOverflow, “Every IdP which supports SAML2 and OpenId Connect and KeyCloak OpenId Connect”
در KeyCloak می توان یک سرویس REST را Secure کرد. به این معنی که برای فراخوانی این سرویس REST باید از KeyCloak توکن گرفت (با دادن username و password) و سپس سرویس REST را به همراه توکن فراخوانی کرد.
در KeyCloak می توان با استفاده از Import/Export API داده های یک Realm را به صورت Json ، exportکرد. این ویژگی زمانی به کمک می آید که بخواهیم از یک گلستانش KeyCloak به گلستانش بعدی سوییچ کنیم و نیاز است داده های Realm را از نسخه ی قبل به نسخه ی جدید Import کنیم.
Gluu Server
پروتکل هایی که ساپورت می کند:
گلوو هم از جمله IdP های Linux-base است. یکی از مشکلات Gluu نداشتن Distribution ویندوز است. مشکل اصلی Gluu Server عدم پشتیبانی از مفهوم Realm است.
https://wikis.forgerock.org/confluence/display/openam/Use+OpenAM+RESTful+Services
OpenAM (OpenSSO)
نقطه ضعف این IdP بیش از حد پیچیده بودن مفاهیم و واسط کاربری آن است البته در کار با واسط کاربری آن این نکته مشخص است.
نقطه ضعف دیگر این IdP ضعیف بودن سرویس REST آن است. در مقایسه با KeyCloak سرویس REST آن بسیار ناقص است.
استفاده از این محصول توصیه نمی شود زیرا comment هایی مشابه زیر در مورد آن وجود دارد:
https://evolveum.com/blog/comparing-disasters/
یکی از ویژگی های خاص OpenAM نوع خاصی از Authentication به نام Push Authentication است. در این نوع Authentication با کمک گرفتن از تلفن همراه کاربر می توان عمل لاگین بر روی سایت را بدون وارد کردن پسورد انجام داد. در حال حاضر IdP های دیگر این نوع Authentication را پشتیبانی نمی کنند.
JOSSO
اولین نقطه ضعف JOSSO (نسخه ی Community Edition) عدم پشتیبانی از feature های زیادی است که نسخه ی پولی آن یعنی Enterprise Edition ارایه می دهد. مثلا مفاهیم Role و Permission در نسخه Community Edition پشتیبانی نمی شوند. به نظر اینجانب عدم این پشتیبانی به حدی هست که JOSSO را از لیست انتخاب های موجود حذف کند.
Shibboleth Identity Provider
اولین نقطه ضعف Shibboleth پشتیبانی نکردن از پروتکل OpenId Connect است. Shibboleth تنها پروتکل های SAML1 و SAML2 و CAS 2 را پوشش می دهد.
بزرگترین نقطه ضعف Shibboleth نداشتن واسط کاربری است. به نظر Gluu Server به صورت built-in از Shibboleth برای مدیریت کاربران استفاده می کند و معمولا Shibboleth همراه Gluu Server نصب و استفاده می شود تا از واسط کاربری Gluu Server برای مدیریت Shibboleth استفاده شود.
به صورت خلاصه می توان بین IdP های موجود خلاصه ای به شکل زیر ایجاد کرد:
https://access.redhat.com/solutions/1129963
ساپورت IdP های موجود
در حال حاضر KeyCloak از سوی RedHat تحت عنوان RedHat SSO پشتیبانی می شود.
https://forgerock.org/2016/07/using-push-notifications-passwordless-authentication-easy-mfa/
چگونگی پیاده سازی SSO برای موبایل
SSO بر روی موبایل بدین معنی است که وقتی کاربر بر روی App1 از موبایل با نام کاربری و رمز عبور لاگین کرد، برای اجرا کردن App2 دیگر لازم نباشد نام کاربری و رمز عبور خاص App2 را وارد کند. در حقیقت بین App های موبایل SSO ایجاد می گردد.
برای پیاده سازی حالت خاصی از SSO بدین معنی که در هنگامی که کاربر از طریق وب لاگین می کند(از طریق IdP) یک Push Notification برای گوشی کاربر ارسال می شود و گوشی در پس زمینه کاربر را لاگین و توکن را ذخیره می کند. عمل لاگین که در پس زمینه صورت می گیرد توسط یک App خاص به نام Account Manager صورت می گیرد.در این سناریو لازم است یک بار نام کاربری و رمز عبور شخص برای 1App در Account Manager ذخیره گردد تا با دریافت Push Notification، Account Manager به IdP درخواست Authentication با نام کاربری و رمز عبور ذخیره شده ارسال نماید. البته در مورد این پیاده سازی مطمین نیستم ولی با مطالعه مستندات OpenAm تا حدی می توان روش را حدس زد. لینک اول بالای Section روشی را توضیح می دهد که تا حدی به این پیاده سازی نزدیک است.
http://blog.keycloak.org/2016/03/commercial-support.html
جمع بندی
از بین IdP های بیان شده KeyCloak با توجه به دلایل زیر :
1- با آپاچی شیرو از طریق OpenId Connect (از طریق pac4j) و با Spring Security و به طبع با Spring MVC ، integrate است.
2- UI قدرتمند، ساده و قابل فهمی دارد.
3- REST API برای مدیریت داده های کاربران (داده های Realm) دارد.
4- از نظر مدل کردن مفاهیم امنیتی مثل Realm، User، Group، Application (Client) ، Role و ... طراحی بهتری دارد.
5- پیاده سازی پروتکل OpenId Connect در آن ناقص نیست(به غیر از Hybrid Flow که استفاده از این فلو نادر است و عدم وجود آن با توجه به مستندات قابل چشم پوشی است).
6- KeyCloak در حال ادغام شدن با پروژه ی PicketLink است که بر قدرت API آن می افزاید.
7- مشابه بعضی IdP ها فوق العاده پیچیده نیست.
8- SPI ای به نام Event Listener SPI دارد که می توان بر روی Event های سرور Handler نوشت. این کاربرد کمک می کند تا در هنگام لاگین کاربر(Login Event) برای تلفن همراه کاربر Push Notification ارسال کرد.
9- RedHat در حال آماده سازی نسخه ی تجاری KeyCloak است.
10- امکان Import و Export کردن داده های دیتابیس به فرمت Json.
11- با توجه به مقالات موجود به نظر KeyCloak دو امکانی که در ادامه بیان می شود را هم داراست که اولی عبارت است از Secure کردن وب سرویس های RESTFul با استفاده از آن و دوم Secure کردن SPA ها توسط آن(Single Page Application ها) به این معنی که برای SPA ها لایبراری javascript فراهم کرده است.
به نظر وضعیت مطلوب تری دارد و بعد از آن WSO2 با توجه به مدل خوبی که برای User Federation دارد به نظر مطلوب است. ویژگی User Federation به این معنی است که می توان WSO2 را به نحوی پیکر بندی کرد که با چند دیتابیس کاستوم کار کند(و پیاده سازی این ویژگی در WSO2 از KeyCloak قوی تر است). CAS Server تنها از این نظر دارای حسن است که توسط لایبراری pac4j با شیرو سازگار است. به غیر از این ویژگی، نه UI مناسبی برای کار دارد و نه REST API ای برای مدیریت اطلاعات. به علاوه pac4j امکان استفاده از یک IdP که پروتکل OpenId Connect را پشتیبانی کند را فراهم می کند که به همین دلیل می توان از آن و از شیرو به همراه KeyCloak استفاده کرد.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
#معماری_نرم_افزار_بهشتی
