در هر شرکت بزرگی، و X5 Retail Group نیز از این قاعده مستثنی نیست، با توسعه آن، تعداد پروژه هایی که نیاز به مجوز کاربر دارند افزایش می یابد. با گذشت زمان، انتقال یکپارچه کاربران از یک برنامه به برنامه دیگر مورد نیاز است و پس از آن نیاز به استفاده از یک سرور Sing-On (SSO) وجود دارد. اما در مورد زمانی که ارائه دهندگان هویت مانند AD یا سایرین که ویژگی های اضافی ندارند قبلاً در پروژه های مختلف استفاده می شوند چه می شود. دسته ای از سیستم ها به نام "کارگزاران شناسایی" به کمک خواهند آمد. عملکردی ترین آنها نمایندگان آن هستند، مانند Keycloak، مدیریت دسترسی Gravitee، و غیره. اغلب موارد استفاده می تواند متفاوت باشد: تعامل ماشین، مشارکت کاربر و غیره. و چنین راه حل هایی شرکت ما اکنون دارای یک کارگزار نشانه - Keycloak است.
Keycloak یک محصول منبع باز هویت و کنترل دسترسی است که توسط RedHat نگهداری می شود. این اساس محصولات این شرکت با استفاده از SSO - RH-SSO است.
مفاهیم پایه
قبل از شروع به پرداختن به راه حل ها و رویکردها، باید بر اساس شرایط و ترتیب فرآیندها تصمیم بگیرید:
شناسایی روشی برای تشخیص یک موضوع توسط شناسه او (به عبارت دیگر، این تعریف یک نام، ورود یا شماره است).
احراز هویت - این یک روش احراز هویت است (کاربر با رمز عبور بررسی می شود، نامه با امضای الکترونیکی بررسی می شود و غیره)
اجازه - این امکان دسترسی به یک منبع (مثلاً به ایمیل) است.
Keycloak کارگزار هویت
شنل کلید یک راه حل مدیریت دسترسی و هویت منبع باز است که برای استفاده در IS طراحی شده است که در آن می توان از الگوهای معماری میکروسرویس استفاده کرد.
Keycloak ویژگی هایی مانند ورود به سیستم واحد (SSO)، هویت واسطه ای و ورود به سیستم اجتماعی، فدراسیون کاربر، آداپتورهای مشتری، کنسول مدیریت و کنسول مدیریت حساب را ارائه می دهد.
عملکرد اصلی پشتیبانی شده توسط Keycloak:
- Single-Sign On و Single-Sign Out برای برنامه های مرورگر.
- پشتیبانی از OpenID/OAuth 2.0/SAML.
- Identity Brokering - احراز هویت با استفاده از OpenID Connect یا ارائه دهندگان هویت SAML خارجی.
- ورود به سیستم اجتماعی - پشتیبانی گوگل، گیت هاب، فیس بوک، توییتر برای شناسایی کاربر.
- فدراسیون کاربر - همگام سازی کاربران از سرورهای LDAP و Active Directory و سایر ارائه دهندگان هویت.
- پل Kerberos - با استفاده از سرور Kerberos برای احراز هویت خودکار کاربر.
- Admin Console - برای مدیریت یکپارچه تنظیمات و گزینه های راه حل از طریق وب.
- کنسول مدیریت حساب - برای مدیریت شخصی نمایه کاربر.
- سفارشی سازی راه حل بر اساس هویت شرکتی.
- 2FA Authentication - پشتیبانی TOTP/HOTP با استفاده از Google Authenticator یا FreeOTP.
- جریان های ورود - ثبت نام خود کاربر، بازیابی رمز عبور و تنظیم مجدد، و موارد دیگر امکان پذیر است.
- مدیریت جلسه - مدیران می توانند جلسات کاربر را از یک نقطه مدیریت کنند.
- Token Mappers - ویژگی های کاربر، نقش ها و سایر ویژگی های مورد نیاز را به نشانه ها متصل می کند.
- مدیریت خط مشی انعطاف پذیر در قلمرو، برنامه و کاربران.
- پشتیبانی CORS - آداپتورهای مشتری دارای پشتیبانی داخلی CORS هستند.
- رابط های ارائه دهنده خدمات (SPI) - تعداد زیادی SPI که به شما امکان می دهد جنبه های مختلف سرور را سفارشی کنید: جریان های احراز هویت، ارائه دهندگان هویت، نگاشت پروتکل و موارد دیگر.
- آداپتورهای سرویس گیرنده برای برنامه های جاوا اسکریپت، WildFly، JBoss EAP، Fuse، Tomcat، Jetty، Spring.
- پشتیبانی از کار با برنامه های مختلف که از کتابخانه OpenID Connect Relying Party یا کتابخانه ارائه دهنده خدمات SAML 2.0 پشتیبانی می کنند.
- قابل ارتقا با استفاده از پلاگین ها
برای فرآیندهای CI / CD و همچنین اتوماسیون فرآیندهای مدیریت در Keycloak، می توان از REST API / JAVA API استفاده کرد. اسناد به صورت الکترونیکی در دسترس است:
REST API
Java API
ارائه دهندگان هویت سازمانی (در محل)
امکان احراز هویت کاربران از طریق خدمات فدراسیون کاربر.
همچنین می‌توان از احراز هویت عبوری استفاده کرد - اگر کاربران در برابر ایستگاه‌های کاری با Kerberos (LDAP یا AD) احراز هویت شوند، می‌توانند به طور خودکار به Keycloak بدون نیاز به وارد کردن نام کاربری و رمز عبور خود احراز هویت شوند.
برای احراز هویت و مجوز بیشتر کاربران، می‌توان از یک DBMS رابطه‌ای استفاده کرد که بیشتر برای محیط‌های توسعه کاربرد دارد، زیرا شامل تنظیمات و ادغام طولانی در مراحل اولیه پروژه نمی‌شود. به طور پیش فرض، Keycloak از یک DBMS داخلی برای ذخیره تنظیمات و داده های کاربر استفاده می کند.
لیست DBMS های پشتیبانی شده گسترده است و شامل: MS SQL، Oracle، PostgreSQL، MariaDB، Oracle و غیره است. بیشترین تست شده تا کنون Oracle 12C Release1 RAC و Galera 3.12 cluster برای MariaDB 10.1.19 هستند.
ارائه دهندگان هویت - ورود به سیستم اجتماعی
امکان استفاده از لاگین از شبکه های اجتماعی وجود دارد. برای فعال کردن قابلیت احراز هویت کاربران، از کنسول مدیریت Keycloack استفاده کنید. نیازی به تغییر در کد برنامه نیست و این قابلیت خارج از جعبه در دسترس است و می تواند در هر مرحله از پروژه فعال شود.
امکان استفاده از ارائه دهندگان OpenID/SAML Identity برای احراز هویت کاربر وجود دارد.
سناریوهای مجوز معمول با استفاده از OAuth2 در Keycloak
جریان کد مجوز - با برنامه های سمت سرور استفاده می شود. یکی از رایج‌ترین انواع مجوزهای مجوز، زیرا برای برنامه‌های سروری که کد منبع برنامه و داده‌های سرویس گیرنده در دسترس افراد خارجی نیست، مناسب است. فرآیند در این مورد بر اساس تغییر مسیر است. برنامه باید بتواند با یک عامل کاربر (user-agent)، مانند یک مرورگر وب، ارتباط برقرار کند تا کدهای مجوز API را که از طریق عامل کاربر هدایت می شوند، دریافت کند.
جریان ضمنی - مورد استفاده توسط برنامه های کاربردی تلفن همراه یا وب (برنامه های در حال اجرا بر روی دستگاه کاربر).
نوع مجوز ضمنی مجوز توسط برنامه های کاربردی تلفن همراه و وب استفاده می شود که محرمانه بودن مشتری نمی تواند تضمین شود. نوع مجوز ضمنی نیز از تغییر مسیر عامل کاربر استفاده می کند که به موجب آن رمز دسترسی برای استفاده بیشتر در برنامه به عامل کاربر ارسال می شود. این توکن را در اختیار کاربر و سایر برنامه های موجود در دستگاه کاربر قرار می دهد. این نوع مجوز مجوز هویت برنامه را تأیید نمی کند و خود فرآیند به URL تغییر مسیر (که قبلاً در سرویس ثبت شده است) متکی است.
جریان ضمنی از نشانه های بازخوانی نشانه دسترسی پشتیبانی نمی کند.
جریان اعطای اعتبار مشتری - زمانی استفاده می شود که برنامه به API دسترسی پیدا کند. این نوع مجوز مجوز معمولاً برای تعاملات سرور به سرور استفاده می شود که باید در پس زمینه بدون تعامل فوری کاربر انجام شود. جریان اعطای اعتبار مشتری به یک سرویس وب (مشتری محرمانه) اجازه می دهد تا از اعتبار خود به جای جعل هویت کاربر برای احراز هویت در هنگام تماس با سرویس وب دیگر استفاده کند. برای سطح بالاتر امنیت، این امکان وجود دارد که سرویس تماس از یک گواهی (به جای راز مشترک) به عنوان اعتبار استفاده کند.
مشخصات OAuth2 در شرح داده شده است
توکن JWT و مزایای آن
JWT (JSON Web Token) یک استاندارد باز است () که یک روش فشرده و مستقل را برای انتقال ایمن اطلاعات بین طرفین به عنوان یک شی JSON تعریف می کند.
طبق استاندارد، توکن از سه قسمت در قالب پایه-64 تشکیل شده است که با نقطه از هم جدا شده اند. قسمت اول هدر نام دارد که شامل نوع توکن و نام الگوریتم هش برای به دست آوردن امضای دیجیتال است. بخش دوم اطلاعات اولیه (کاربر، ویژگی ها و غیره) را ذخیره می کند. بخش سوم امضای دیجیتال است.
. .
هرگز توکنی را در DB خود ذخیره نکنید. از آنجایی که یک رمز معتبر معادل رمز عبور است، ذخیره رمز مانند ذخیره رمز عبور در متن واضح است.
نشانه دسترسی توکنی است که به مالک خود امکان دسترسی به منابع سرور امن را می دهد. معمولاً عمر کوتاهی دارد و ممکن است حاوی اطلاعات اضافی مانند آدرس IP طرف درخواست کننده توکن باشد.
نشانه تازه کردن توکنی است که به مشتریان این امکان را می دهد تا پس از پایان عمرشان، توکن های دسترسی جدید را درخواست کنند. این توکن ها معمولا برای مدت طولانی صادر می شوند.
مزایای اصلی استفاده در معماری میکروسرویس:
- امکان دسترسی به اپلیکیشن ها و سرویس های مختلف از طریق احراز هویت یک بار.
- در غیاب تعدادی از ویژگی های مورد نیاز در نمایه کاربر، می توان با داده هایی که می تواند به محموله اضافه شود، از جمله خودکار و در حال پرواز، غنی سازی کرد.
- نیازی به ذخیره اطلاعات مربوط به جلسات فعال نیست، برنامه سرور فقط باید امضا را تأیید کند.
- کنترل دسترسی انعطاف پذیرتر از طریق ویژگی های اضافی در بار.
- استفاده از امضای توکن برای هدر و بارگذاری، امنیت راه حل را به طور کلی افزایش می دهد.
نشانه JWT - ترکیب
عنوان - به طور پیش فرض، هدر فقط شامل نوع رمز و الگوریتم مورد استفاده برای رمزگذاری است.
نوع توکن در کلید "typ" ذخیره می شود. کلید "نوع" در JWT نادیده گرفته می شود. اگر کلید "typ" وجود داشته باشد، مقدار آن باید JWT باشد تا نشان دهد این شی یک توکن وب JSON است.
کلید دوم "alg" الگوریتم مورد استفاده برای رمزگذاری رمز را تعریف می کند. به طور پیش فرض باید روی HS256 تنظیم شود. هدر در base64 کدگذاری شده است.
{ "alg": "HS256", "type": "JWT"}
محموله (محتوا) - محموله هر اطلاعاتی را که باید بررسی شود ذخیره می کند. هر کلید در محموله به عنوان "ادعا" شناخته می شود. به عنوان مثال، شما می توانید تنها با دعوت (تبلیغات بسته) وارد برنامه شوید. زمانی که می خواهیم فردی را برای شرکت دعوت کنیم، برای او دعوت نامه می فرستیم. مهم است که بررسی کنید که آدرس ایمیل متعلق به شخصی است که دعوت را پذیرفته است، بنابراین ما این آدرس را در بار وارد می کنیم، برای این کار آن را در کلید "ایمیل" ذخیره می کنیم.
{ "پست الکترونیک": "[ایمیل محافظت شده]"}
کلیدهای موجود در محموله ممکن است دلخواه باشند. با این حال، چند مورد رزرو وجود دارد:
- iss (Issuer) - برنامه ای را که رمز از آن ارسال می شود را مشخص می کند.
- sub (موضوع) - موضوع نشانه را تعریف می کند.
- aud (مخاطب) آرایه ای از رشته ها یا URI های حساس به حروف بزرگ و کوچک است که لیستی از گیرندگان این نشانه است. هنگامی که طرف دریافت کننده یک JWT با کلید داده شده دریافت می کند، باید وجود خود را در گیرنده ها بررسی کند - در غیر این صورت توکن را نادیده بگیرید.
- exp (زمان انقضا) - زمان انقضای توکن را نشان می دهد. استاندارد JWT تمام پیاده‌سازی‌هایش را ملزم می‌کند که توکن‌های منقضی شده را رد کنند. کلید exp باید یک مهر زمانی در قالب یونیکس باشد.
- nbf (Not Before) زمانی در قالب یونیکس است که لحظه معتبر شدن توکن را تعیین می کند.
- iat (Issued At) - این کلید زمان صدور توکن را نشان می دهد و می تواند برای تعیین سن JWT استفاده شود. کلید iat باید یک مهر زمانی در قالب یونیکس باشد.
- Jti (JWT ID) - رشته‌ای که شناسه منحصربه‌فرد این توکن حساس به حروف کوچک و بزرگ را تعریف می‌کند.
درک این نکته مهم است که محموله به صورت رمزگذاری شده منتقل نمی شود (اگرچه توکن ها می توانند تودرتو باشند و سپس امکان انتقال داده های رمزگذاری شده وجود دارد). بنابراین نمی تواند هیچ اطلاعات سری را ذخیره کند. مانند هدر، محموله هم از نوع base64 کدگذاری شده است.
امضا - وقتی عنوان و باربری داریم می توانیم امضا را محاسبه کنیم.
Base64-encoded: هدر و محموله گرفته می شوند، آنها از طریق یک نقطه در یک رشته ترکیب می شوند. سپس این رشته و کلید مخفی به الگوریتم رمزگذاری مشخص شده در هدر (کلید "alg") وارد می شوند. کلید می تواند هر رشته ای باشد. رشته های بلندتر ترجیح داده می شوند زیرا برداشتن آنها زمان بیشتری می برد.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
ساخت یک معماری خوشه‌ای Failover Keycloak
هنگام استفاده از یک کلاستر برای همه پروژه ها، نیازهای بیشتری برای راه حل SSO وجود دارد. هنگامی که تعداد پروژه ها کم باشد، این الزامات برای همه پروژه ها چندان قابل توجه نیست، با این حال، با افزایش تعداد کاربران و ادغام، الزامات در دسترس بودن و عملکرد افزایش می یابد.
افزایش ریسک خرابی تک SSO الزامات معماری راه حل و روش های مورد استفاده برای اجزای اضافی را افزایش می دهد و منجر به SLA بسیار فشرده می شود. در این راستا، اغلب در طول توسعه یا مراحل اولیه اجرای راه‌حل‌ها، پروژه‌ها زیرساخت‌های غیر قابل تحمل خود را دارند. همانطور که توسعه پیشرفت می کند، لازم است فرصت هایی برای توسعه و مقیاس گذاری در نظر گرفته شود. ایجاد یک خوشه شکست با استفاده از مجازی سازی کانتینر یا یک رویکرد ترکیبی بسیار انعطاف پذیر است.
برای کار در حالت‌های خوشه‌ای Active/Active و Active/Passive، لازم است از سازگاری داده‌ها در یک پایگاه داده رابطه‌ای اطمینان حاصل شود - هر دو گره پایگاه داده باید به طور همزمان بین مراکز داده مختلف با توزیع جغرافیایی تکرار شوند.
ساده ترین مثال نصب مقاوم در برابر خطا.
مزایای استفاده از یک خوشه منفرد چیست:
- در دسترس بودن و عملکرد بالا.
- پشتیبانی از حالت های عملیاتی: فعال / فعال، فعال / غیرفعال.
- قابلیت مقیاس بندی پویا - هنگام استفاده از مجازی سازی کانتینر.
- امکان مدیریت و نظارت متمرکز.
- رویکرد یکپارچه برای شناسایی / احراز هویت / مجوز کاربران در پروژه ها.
- تعامل شفاف تر بین پروژه های مختلف بدون دخالت کاربر.
- امکان استفاده مجدد از توکن JWT در پروژه های مختلف.
- تنها نقطه اعتماد
- راه‌اندازی سریع‌تر پروژه‌ها با استفاده از میکروسرویس‌ها/مجازی‌سازی کانتینر (بدون نیاز به بلند کردن و پیکربندی اجزای اضافی).
- امکان خرید پشتیبانی تجاری از فروشنده وجود دارد.
هنگام برنامه ریزی یک خوشه به دنبال چه چیزی باشید
DBMS
Keycloak از یک سیستم مدیریت پایگاه داده برای ذخیره سازی: قلمروها، مشتریان، کاربران و غیره استفاده می کند.
طیف گسترده ای از DBMS پشتیبانی می شود: MS SQL، Oracle، MySQL، PostgreSQL. Keycloak با پایگاه داده رابطه ای داخلی خود ارائه می شود. توصیه می شود برای محیط های بدون بار استفاده شود - مانند محیط های توسعه.
برای کار در حالت‌های خوشه‌ای Active/Active و Active/Passive، سازگاری داده‌ها در یک پایگاه داده رابطه‌ای مورد نیاز است و هر دو گره خوشه پایگاه داده به طور همزمان بین مراکز داده تکرار می‌شوند.
حافظه پنهان توزیع شده (Infinspan)
برای اینکه خوشه به درستی کار کند، همگام سازی بیشتر انواع کش های زیر با استفاده از شبکه داده JBoss مورد نیاز است:
جلسات احراز هویت - برای ذخیره داده ها هنگام احراز هویت یک کاربر خاص استفاده می شود. درخواست‌های این کش معمولاً فقط شامل مرورگر و سرور Keycloak می‌شود، نه برنامه.
توکن‌های اکشن برای سناریوهایی استفاده می‌شوند که در آن کاربر نیاز به تایید یک عمل به صورت ناهمزمان (از طریق ایمیل) دارد. به عنوان مثال، در طول یک جریان فراموشی رمز عبور، کش actionTokens Infinispan برای پیگیری فراداده‌های مربوط به نشانه‌های اقدام مرتبط که قبلاً استفاده شده‌اند استفاده می‌شود، بنابراین نمی‌توان از آن دوباره استفاده کرد.
ذخیره سازی و نامعتبر کردن داده های پایدار - برای جلوگیری از درخواست های غیر ضروری در پایگاه داده برای ذخیره سازی داده های پایدار استفاده می شود. هنگامی که هر سرور Keycloak داده ها را به روز می کند، همه سرورهای Keycloak دیگر در تمام مراکز داده باید در مورد آن اطلاعات داشته باشند.
Work - فقط برای ارسال پیام های نامعتبر بین گره های خوشه و مراکز داده استفاده می شود.
جلسات کاربر - برای ذخیره اطلاعات مربوط به جلسات کاربر که برای مدت زمان جلسه مرورگر کاربر معتبر هستند استفاده می شود. کش باید درخواست های HTTP از کاربر نهایی و برنامه را پردازش کند.
محافظت از نیروی بی رحم - برای ردیابی داده های مربوط به ورود ناموفق استفاده می شود.
تعادل بار
متعادل کننده بار تنها نقطه ورود به keycloak است و باید از جلسات چسبنده پشتیبانی کند.
سرورهای کاربردی
آنها برای کنترل تعامل اجزا با یکدیگر استفاده می شوند و می توانند با استفاده از ابزارهای اتوماسیون موجود و مقیاس بندی پویا ابزارهای اتوماسیون زیرساخت مجازی یا کانتینری شوند. رایج ترین سناریوهای استقرار در OpenShift، Kubernates، Rancher.
این پایان بخش اول - بخش نظری است. در سری بعدی مقالات، نمونه هایی از ادغام با ارائه دهندگان هویت مختلف و نمونه هایی از تنظیمات مورد تجزیه و تحلیل قرار خواهند گرفت.
منبع: www.habr.com