https://virgool.io/feed/@mr.mahdi361 fa 2026-06-17 02:42:13 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@mr.mahdi361 https://virgool.io/@mr.mahdi361/%D8%AA%D8%B9%D8%A7%D8%B1%DB%8C%D9%81-%D9%88%D8%A7%DA%98%DA%AF%D8%A7%D9%86-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-dmkzqma8bell طراحی دامنه محور :Domain Driven Design (DDD) راهی برای توسعه آسان‌تر نرم‌افزار پیچیده با ترجمه آن به قطعات کوچک متصل در یک مدل همیشه در حال تکامل از منطق اصلی تجارت است. این یک روش و نسخه فرآیندی برای توسعه سیستم های پیچیده است. تمرکز DDD نگاشت فرآیندهای تجاری در یک حوزه مشکل به مصنوعات فناوری یک حوزه راه حل است.فرض آن این است:· تمرکز اصلی پروژه را روی دامنه اصلی و منطق دامنه قرار دهید· طرح های پیچیده را بر روی یک مدل قرار دهید· همکاری خلاقانه بین متخصصان فنی و حوزه را آغاز کنید تا به طور مکرر به قلب مفهومی مشکل نزدیک‌تر شوید.ساده به نظر می رسد، اما کشیدن آن در دنیای واقعی پیچیده سخت است. نیاز به مهارت‌ها، نظم و انضباط جدید و رویکردی سیستماتیک دارد.دامنه چیست؟دامنه یک مرز برای یک مشکل تجاری است که باید توسط نرم افزار حل شود. اما چگونه می توان دامنه را شناخت؟ با درگیر کردن متخصصانی که به آنها متخصص دامنه نیز گفته می شود. اینها افرادی هستند که دانش را انتقال می دهند، دامنه را ارتقا می دهند و به شما اجازه می دهند آن را درک کنید. آنها همچنین به شما کمک می کنند تا دامنه را بر اساس تجزیه کسب و کار به بلوک ها بر اساس خطوط کسب و کار، ترویج مالکیت و افزایش کنترل، ساده سازی به بلوک ها و کاهش خطر تغییر مدل کنید.قوانین کلی هنگام طراحی مدل1. روی حوزه اصلی تمرکز کنید2. طراحی یک مدل در یک همکاری خلاقانه بین افراد دامنه و افراد نرم افزار· طراحی توسط کسب و کارo وابستگی های قوی بین هر دامنه مجاز نیست، از برخورد جلوگیری می کند و استقلال را ارتقا می دهد.· جفت شدن آزادانه بین دامنه هاo وابستگی های قوی بین هر دامنه مجاز نیست، از برخورد جلوگیری می کند و استقلال را ارتقا می دهد.· از چرخه های زندگی مستقل اطمینان حاصل کنیدo اطمینان حاصل کنید که هر خط از کسب و کار ترجمه شده به دامنه، دارای یک چرخه زندگی واضح و جدا شده است3. به زبانی همه جا صحبت کنید تا همه ذینفعان به طور کامل یکدیگر را درک کنند و بتوانند به طور موثر کار کنندمعماری شش ضلعی :‌معماری شش ضلعی استقرار برنامه ها را بدون رابط کاربری یا پایگاه داده آنها تسهیل می کند - و آنها را قادر می سازد جدا از محیط تکنولوژیکی خارجی اجرا شوند. ماهیت معماری شش ضلعی جداسازی هسته سیستم از دنیای بیرونی است. این یک مشکل کلیدی را حل می کند - آزمایش پذیری معماری. معماری شش ضلعی ما را قادر می سازد تا برنامه های کاربردی قابل آزمایش را از طریق وارونگی وابستگی بسازیم.در معماری سنتی لایه‌ای، پایگاه داده در مرکز سیستم قرار دارد، سیستم بدون پایگاه داده نمی‌تواند کار کند. بنابراین، دنباله ای که توسعه دهندگان باید سیستم را بسازند به شرح زیر است:ابتدا لایه پایگاه داده را پیاده سازی کنید - پایگاه داده قلب سیستم استدوم، لایه منطق تجاری را پیاده سازی کنید، که به لایه پایگاه داده بستگی دارد - لایه منطق تجاری داده ها را از پایگاه داده می خواند، منطق تجاری را انجام می دهد و داده ها را در پایگاه داده ذخیره می کند.ثالثاً، لایه ارائه را پیاده سازی کنید، معمولاً برخی از UI، که به لایه منطق تجاری اشاره می کند، اما ممکن است مستقیماً به لایه پایگاه داده نیز ارجاع دهد.تنها راهی که می‌توانیم برنامه را اجرا کنیم (و آزمایش کنیم) با پایگاه داده و رابط کاربری است. برنامه به نگرانی های تکنولوژیکی بستگی دارد. این باعث دو مشکل می شود:زمانی که برنامه ما نیاز به کار با فناوری ارائه دیگری دارد، دوباره کاری گران قیمت استزمانی که برنامه ما نیاز به تغییر به فناوری پایگاه داده دیگری دارد، دوباره کاری گران قیمت استبرای نشان دادن مشکل اول - برنامه موجود ممکن است دارای یک رابط کاربری گرافیکی باشد، اما به دلیل نیازهای مشتری باید یک REST API وجود داشته باشد تا سیستم های دیگر بتوانند به برنامه ما متصل شوند. در معماری لایه‌ای سنتی ممکن است نیاز به بازنویسی بخش قابل توجهی از برنامه‌مان باشد تا بتوانیم از دو لایه ارائه پشتیبانی کنیم.برای نشان دادن مشکل دوم - توسعه منطق تجاری ممکن است با انتظار در توسعه پایگاه داده مسدود شود. علاوه بر این، در صورتی که ما نیاز به تغییر به یک فناوری پایگاه داده متفاوت داشته باشیم، یا به طور قابل توجهی طرح پایگاه داده را تغییر دهیم، یا ORM را انتقال دهیم، آنگاه این امر بر کل برنامه تأثیر می گذارد.در نهایت، ما نمی‌توانیم رفتار برنامه را به‌صورت مجزا آزمایش کنیم، زیرا برای اجرای آزمایش‌ها به رابط کاربری و پایگاه داده نیاز داریم که در حال اجرا باشند. این منجر به آزمایش‌های آهسته و شکننده می‌شود و اتوماسیون تست را به یک تلاش گران قیمت و بی‌اثر تبدیل می‌کند.در معماری شش ضلعی، ما از اصل وارونگی وابستگی (DIP - مانند SOLID) استفاده می کنیم تا برنامه را از نگرانی های تکنولوژیکی خارجی جدا کنیم، به طوری که بتوانیم برنامه را به صورت مجزا از UI و پایگاه داده، شبکه اجرا کنیم (و آزمایش کنیم). و هر گونه نگرانی فنی معماری دیگر. ما در حال آزمایش رفتار برنامه به صورت مجزا و بدون هیچ فناوری هستیم.با معکوس کردن وابستگی ها در معماری لایه ای سنتی، معماری نشان داده شده در شکل را دریافت می کنیم.به طور رسمی تر، هدف اساسی معماری شش ضلعی این است که «برنامه خود را ایجاد کنید تا بدون رابط کاربری یا پایگاه داده کار کند تا بتوانید تست های رگرسیون خودکار را در برابر برنامه اجرا کنید، زمانی که پایگاه داده در دسترس نیست کار کنید، و برنامه ها را بدون هیچ کاربری به یکدیگر پیوند دهید. مشارکت" و هدف معماری شش ضلعی این است که "اجازه می دهد یک برنامه کاربردی به همان اندازه توسط کاربران، برنامه ها، اسکریپت های آزمایشی یا دسته ای خودکار در سمت سرور قرار گیرد و جدا از دستگاه ها و پایگاه داده های زمان اجرا نهایی آن توسعه و آزمایش شود" ( آلیستر کاکبرن، https://alistair.cockburn.us/hexagonal-architecture/).این ما را قادر می‌سازد آداپتورهای سمت کاربر (یعنی برنامه را می‌توان به طور مساوی توسط برخی از UI، REST API، تست‌ها اجرا کرد) و آداپتورهای سمت سرور (یعنی برنامه را می‌توان به هر پایگاه داده یا شخص ثالثی متصل کرد) وصل کرد. خدمات). در نتیجه، می‌توانیم پیاده‌سازی‌های تکنولوژیک را عوض کنیم. معماری شش ضلعی همچنین به عنوان پایه ای برای معماری های بعدی مانند معماری پیاز و معماری پاک عمل کرد - هر دو مفهوم اساسی را دارند که هسته برنامه از دنیای بیرون جدا شده است.الگوی CQRS :Command Query Responsibility Segregation (CQRS) یک الگوی معماری نرم افزار است که مسئولیت های خواندن و نوشتن داده ها را در یک سیستم از هم جدا می کند. در CQRS، سیستم به دو بخش مجزا تقسیم می‌شود، یک سمت فرمان و یک سمت پرس و جو، که هر کدام مجموعه‌ای از مسئولیت‌ها و ساختار داده‌های خاص خود را دارند.مزایامزیت اصلی استفاده از CQRS این است که امکان مقیاس پذیری و عملکرد بالا در سیستم را فراهم می کند. از آنجایی که دو طرف Command و Query مجزا هستند، می توان آنها را به طور مستقل بهینه سازی و مقیاس بندی کرد تا بارهای کاری مختلف خواندن و نوشتن داده ها را مدیریت کند. علاوه بر این، جداسازی نگرانی ها را ترویج می کند و حفظ و تکامل سیستم را در طول زمان آسان تر می کند.مزیت دیگر CQRS این است که امکان مدیریت آسان منطق تجاری پیچیده را فراهم می کند. از آنجایی که سمت Command مسئول اعتبارسنجی و اجرای دستورات است، می‌تواند قوانین پیچیده تجاری و اعتبارسنجی را بدون تأثیر بر عملکرد سمت Query مدیریت کند.معایبعیب اصلی استفاده از CQRS این است که می تواند به سیستم پیچیدگی دهد. از آنجایی که دو طرف Command و Query از هم جدا هستند، همگام نگه داشتن آنها و اطمینان از سازگاری داده ها بین آنها می تواند چالش برانگیز باشد. علاوه بر این، طراحی سیستم به گونه ای که اطمینان حاصل شود که دو طرف Command و Query به طور سست جفت شده اند و منجر به ایجاد وابستگی بین آنها نمی شود، می تواند دشوار باشد.در نتیجه، CQRS یک ابزار قدرتمند برای ساختن سیستم هایی است که به مقیاس پذیری و عملکرد بالا نیاز دارند. این امکان را برای درجه بالایی از مقیاس پذیری و عملکرد فراهم می کند و باعث جداسازی نگرانی ها می شود. با این حال، به برنامه ریزی و هماهنگی دقیق نیز نیاز دارد و می تواند به سیستم پیچیدگی بیافزاید. CQRS برای سیستم هایی مناسب است که به مقیاس پذیری بالا، منطق تجاری پیچیده و عملیات خواندن و نوشتن جداگانه نیاز دارند. نمونه هایی از سیستم هایی که می توانند از این معماری بهره مند شوند عبارتند از: پلتفرم های تجارت الکترونیک، سیستم های مالی و بازارهای آنلاین.معماری MVVM :کلید درک معماری MVVM درک چگونگی تعامل سه جزء کلیدی در MVVM با یکدیگر است. از آنجایی که View فقط با ViewModel و ViewModel فقط با Model ارتباط برقرار می کند.تمام تعاملات کاربر در View رخ می دهد، که وظیفه تشخیص ورودی کاربر (کلیک های ماوس، ورودی صفحه کلید) و ارسال آن به ViewModel از طریق اتصال داده ها را بر عهده دارد. اتصال داده‌ها را می‌توان با فراخوانی یا ویژگی‌ها پیاده‌سازی کرد و پیوند مشخصی بین View و ViewModel را تشکیل می‌دهد.ViewModel ویژگی ها و دستوراتی را اجرا می کند که View را می توان به آنها محدود کرد. این ویژگی ها و دستورات عملکردی را که View می تواند به کاربر ارائه دهد را مشخص می کند، اگرچه نحوه نمایش آن کاملاً به View بستگی دارد. ViewModel همچنین وظیفه ارائه داده‌هایی از کلاس‌های Model را بر عهده دارد که View می‌تواند آن‌ها را مصرف کند. برای انجام این کار، ViewModel می‌تواند کلاس‌های Model را مستقیماً در View نمایش دهد، در این صورت کلاس Model باید از اتصال داده‌ها و تغییر رویدادهای اعلان پشتیبانی کند. مدل‌ها کلاس‌هایی هستند که دامنه برنامه را مدل‌سازی می‌کنند. مدل ها داده ها و منطق تجاری برنامه را در بر می گیرند. آنها را می توان اشیاء تجاری در نظر گرفت که مطلقاً هیچ ارتباطی با جنبه بصری برنامه ندارند.مزایای MVVM· توسعه آسان تر: جدا کردن View از منطق باعث می شود که تیم های مختلف به طور همزمان روی اجزای مختلف کار کنند. تیمی از طراحان می‌توانند در حالی که توسعه‌دهندگان روی پیاده‌سازی منطق (ViewModel و Model) کار می‌کنند، روی UI تمرکز کنند.· تست آسان تر: یکی از سخت ترین چیزهایی که در یک برنامه آزمایش می شود، رابط کاربری (UI) است. از آنجایی که ViewModel و Model کاملا مستقل از View هستند، توسعه دهندگان می توانند بدون نیاز به استفاده از View برای هر دو تست بنویسند.· نگهداری آسان تر: جداسازی بین اجزای مختلف برنامه، کد را ساده تر و تمیزتر می کند. در نتیجه، درک کد برنامه بسیار ساده تر است و بنابراین نگهداری می شود. درک اینکه کجا باید ویژگی‌های جدید را پیاده‌سازی کنیم و چگونه به الگوی موجود متصل می‌شوند، آسان‌تر است. با یک MVVM، پیاده‌سازی الگوهای معماری بیشتر (وابستگی وابستگی، خدمات و موارد دیگر) نیز آسان‌تر است.معایب MVVMجان گوسمن، معمار مایکروسافت که اولین بار MVVM را معرفی کرد، معایب اصلی الگو را موارد زیر می داند:· پیچیدگی: MVVM در ایجاد رابط های کاربری ساده بسیار زیاد است. هنگام کار بر روی پروژه‌های بزرگ‌تر، طراحی ViewModel به منظور دستیابی به میزان کلی کلی می‌تواند بسیار دشوار باشد.· اشکال زدایی دشوار است: از آنجایی که اتصال داده ها به صورت اعلانی است، اشکال زدایی آن نسبت به کدهای سنتی و ضروری دشوارتر است.معماری event sourcing :Event Sourcing یک الگوی معماری است که امکان توسعه بسیار کارآمد معماری های رویداد محور را فراهم می کند. در الگوی طراحی، دو نوع وجود دارد: الگوهای تاکتیکی و الگوهای معماری. الگوهای تاکتیکی الگوهای ساختار، رفتار و خلقت هستند. الگوهای ساختار بهترین راه را برای اتصال اشیا نشان می‌دهند تا به آنها اجازه دهد مستقل از تحولات آینده تکامل یابند، به عنوان مثال، چگونه می‌توان برنامه‌ای ایجاد کرد که برای اصلاح بسته و باز است؟ الگوهای رفتاری نشان می‌دهند که چگونه اشیا باید با هم تعامل داشته باشند تا بتوانند یک مشکل را به بهترین شکل حل کنند، و الگوهای ایجاد نشان می‌دهند که بهترین راه برای ایجاد اشیا چیست. الگوهای معماری برای بهبود کیفیت، کارایی و قابلیت اطمینان نرم افزار توسعه استفاده می شود. می‌توانیم الگوی MVC، وارونگی کنترل، تزریق وابستگی، CQRS و منبع‌یابی رویداد را ذکر کنیم. به عنوان مثال، الگوی MVC امکان توسعه لایه ارائه یک برنامه کاربردی را فراهم می کند، این الگو بر اساس الگوهای تاکتیکی زیادی است.Event Sourcing یک الگوی معماری است که شامل ثبت تمام تغییرات حالت یک برنامه کاربردی به عنوان دنباله ای از رویدادها است. این به این معنی است که در یک برنامه، شما نباید روی وضعیت فعلی برنامه تمرکز کنید، بلکه باید تمام رویدادهایی را که در آنجا رخ داده است و به برنامه اجازه می دهد در وضعیت فعلی خود باشد را ثبت کنید. بنابراین مهم است که روی توالی تغییرات حالت (رویدادهای تجاری) که منجر به وضعیت فعلی برنامه می شود، تمرکز کنیم.مثال :بیایید سناریوی زیر را در نظر بگیریم: می خواهیم یک برنامه کاربردی برای مدیریت یک حساب بانکی ایجاد کنیم. اگر امروز حساب خود را بررسی کنید، آنچه مورد توجه شما قرار می گیرد وضعیت آن است، موجودی. اگر من از رویکرد Event Sourcing در سیستم خود استفاده کنم، وضعیت فعلی حساب را ذخیره نمی کنم، بلکه تمام عملیاتی که از زمان ایجاد آن تا کنون روی حساب انجام شده است را ذخیره می کنم. وضعیت فعلی درخواست من از تاریخچه تراکنش هایی که در حساب انجام شده است مشخص می شود.از توالی رویدادها، می توانیم وضعیت فعلی برنامه را جمع آوری کنیم. و این اصل Event Sourcing است که در آن هر تغییر در حالت یک علت واحد دارد.معماری Micro Frontends :هنگامی که رویکرد میکروسرویس را به سمت جلو می‌آوریم، Microfrontends چیزی است که به دست می‌آوریم. به عبارت دیگر، یک microfrontend از اجزایی ساخته شده است - متعلق به تیم های مختلف - که می توانند به طور مستقل مستقر شوند. این اجزا برای ایجاد یک تجربه کاربری ثابت مونتاژ شده اند.با یک میکروفرانتند، هیچ تیمی به تنهایی مالک UI به طور کامل نیست. در عوض، هر تیم صاحب یک قطعه از صفحه، صفحه یا محتوا است. به عنوان مثال، یک تیم ممکن است مسئول کادر جستجو باشد، در حالی که تیم دیگری ممکن است پیشنهادات را بر اساس سلیقه کاربران کدنویسی کند. تیم‌های دیگر ممکن است پخش‌کننده موسیقی را کدنویسی کنند، فهرست‌های پخش را مدیریت کنند یا صفحه صورت‌حساب را ارائه دهند. ما پیچیدگی را اضافه می کنیم، اما تیم ها در ازای آن استقلال بیشتری می گیرند.پلتفرم توسعه کم کد:کسب و کارها با تشدید چرخه های کاری و افزایش ارزش پیشرفت می کنند. در همین حال، توسعه دهندگان و تیم های با تجربه به نقشه راه پروژه های بلند مدت متعهد هستند. در این تقاطع، ابتکارات، ابزار و تکنیک‌های توسعه نرم‌افزار کم‌کد ظهور می‌کند.Low-code یک رویکرد بصری، بسیار انتزاعی و عمدتاً خودکار برای توسعه نرم‌افزار است که وظایف مورد نظر را در سطح بالایی تعریف می‌کند و سپس به ابزارهایی برای تولید بسیاری از کدهای زیربنایی متکی است. توسعه دهندگان حرفه ای و کارکنان خط کسب و کار درک می کنند که مشکلات تجاری می توانند از مفاهیم و شیوه های کم کد برای مقابله با طیف گسترده ای از کارهای برنامه نویسی روزمره استفاده کنند. این می تواند تیم های توسعه دهنده را آزاد کند تا روی پروژه های بزرگتر و پیچیده تر تمرکز کنند.توسعه نرم افزار متعارف مدت هاست که یک تلاش پرزحمت و دقیق بوده است. توسعه دهندگان خطوط جداگانه کد را می نویسند که دستورالعمل ها و داده ها را نشان می دهد. آنها آن کد را در روال ها و ماژول های کاربردی سازماندهی می کنند که ویژگی ها و عملکرد نرم افزار را ارائه می دهند.این رویکرد مستلزم دانش دقیق جنبه‌های مختلف در طیف توسعه برنامه است: زبان‌های توسعه، محیط‌های توسعه مانند محیط‌های توسعه یکپارچه و کامپایلرها، ابزارهای آزمایش و استقرار، و سیاست‌ها و شیوه‌های مختلف مورد استفاده برای رویکرد کدگذاری، آزمایش و استقرار.در مقام مقایسه، فناوری کم‌کد، بسیاری از دانش برنامه‌نویسی را که در غیر این صورت برای ایجاد نرم‌افزار مورد نیاز است، انتزاع و محصور می‌کند. کاربران به جای نوشتن خطوط جداگانه کد، از طریق یک رابط بصری کشیدن و رها کردن، از منوی اجزای کاربردی قابل استفاده مجدد انتخاب می کنند. آنها مولفه های کاربردی موجود را ترتیب و سازماندهی می کنند تا جریان نرم افزار مورد نظر را شکل دهند، شبیه به ایجاد نمودار جریان برای نزدیک شدن به یک مشکل یا کار تجاری. کاربران می توانند به راحتی اجزای کاربردی را برای ساختن فرآیند نهایی اضافه، جابجا یا حذف کنند. در آن مرحله، ابزار کم‌کد، کد زیربنایی و وظایف پشتیبانی، مانند آزمایش و استقرار را در خود جای می‌دهد.درگاه سرویس سازمانی یا ESB :در دنیای امروزی از برنامه های کاربردی پیچیده و متفاوت، معمول است که داده ها در یک برنامه (مانند برنامه مالی شما) ذخیره می شود که در چندین برنامه دیگر (مانند قراردادها یا برنامه های منابع انسانی شما) نیز مورد نیاز است. این اغلب با انتقال داده های دسته ای بین برنامه ها برطرف می شود. متأسفانه، این معمولاً شامل فرآیندهای دستی است که مستعد خطا هستند، که اغلب می‌تواند منجر به اطلاعات قدیمی یا «کهنه» در سیستم‌های اصلی شود که برای عملیات خود به آنها اعتماد می‌کنید.Enterprise Service Bus یا ESB یک راه‌حل فناوری ایده‌آل است که می‌تواند به شما در غلبه بر چالش‌های یکپارچه‌سازی داده‌ها و خدمات در سراسر سازمانتان کمک کند.یک ESB اغلب به عنوان لایه یکپارچه سازی برنامه در معماری سازمانی سازمان با استفاده از اتصال دهنده های هوشمند برای ارائه لایه ای از انتزاع بین اتوبوس و برنامه استفاده می شود. کاربردهای رایج ESB شامل خدمات یکپارچه سازی و تبدیل داده ها به یک ساختار داده مشترک برای مصرف توسط سیستم های انتهایی جایگزین است. ESB اغلب به عنوان ستون فقرات برای ساخت SOA شناخته می شود. ESB یک معماری خدمات توزیع شده مبتنی بر رابط های استاندارد است که میان افزار پیام رسانی، مسیریابی هوشمند و تبدیل پیام را در ارتباط با یک چارچوب امنیتی انعطاف پذیر و زیرساخت مدیریتی برای پیکربندی، استقرار و نظارت بر خدمات ارائه می دهد.API Gateway :یک دروازه API به عنوان یک پروکسی معکوس عمل می کند که بین مجموعه ای از خدمات باطن و یک مشتری قرار می گیرد. دروازه درخواست های API مشتری را می پذیرد و آنها را به میکروسرویس های مناسب هدایت می کند. به طور خلاصه، دروازه API تماس های API را می پذیرد و درخواست ها را برای سرویس های مختلف مورد نیاز جمع می کند. این به عنوان پلی بین پروتکل‌های غیردوستانه وب مورد استفاده داخلی و پروتکل‌های وب که کاربران درک می‌کنند عمل می‌کند.به عنوان مثال، یک سایت تجارت الکترونیک ممکن است از یک دروازه API برای فراخوانی و ترکیب نتایج خدمات مختلف استفاده کند. مانند ترکیب نظرات مشتریان و اطلاعات محصول برای کاربران برای ارائه یک تجربه خرید یکپارچه تر.در سطح سازمانی، بیشتر API ها با استفاده از دروازه های API مستقر می شوند. دروازه‌های API معمولاً وظایف معمولی را برای سرویس‌های مختلف API در سراسر یک سیستم انجام می‌دهند، مانند محدود کردن نرخ و احراز هویت کاربر. آنها همچنین می توانند خطاها را کاهش دهند و کدنویسی را آسان تر کنند و توسعه برنامه های تلفن همراه را کارآمدتر کنند.یک دروازه API چگونه کار می کند؟دروازه API یک نقطه یک ورودی است که در مقابل یک API قرار دارد. امنیت API را برای میکروسرویس ها (که می توانند داخلی و خارجی باشند) و API های back-end تعریف شده اعمال می کند. دروازه API همچنین در دسترس بودن و مقیاس پذیری بالا را تضمین می کند.یک دروازه API پیاده سازی باطن و رابط مشتری در سمت سرور را جدا می کند. تعیین می کند که کدام خدمات برای پاسخ به درخواست های مشتری مورد نیاز است. دروازه API با تقسیم کردن آنها به وظایف متعدد و قابل مدیریت تر، درخواست های مشتری را دریافت کرده و به آنها پاسخ می دهد. این درخواست ها را به سرویس های مناسب هدایت می کند و پاسخ تولید شده را ردیابی می کند.سامانه مدیریت فرآیند های کسب و کار یا BPMS :مدیریت فرآیند کسب و کار روشی است که تیم شما را کارآمد و کسب و کار شما را رقابتی نگه می دارد.سازمان‌هایی که رویه‌های مشخصی ندارند، با تأخیرهای عملیاتی، تهدیدات امنیتی و فرآیندهای گیج‌کننده‌ای مواجه می‌شوند که بر نتایج آنها تأثیر می‌گذارد. استراتژی های BPM مناسب به تیم های شما اجازه می دهد تا مسئولیت های خود را به موقع انجام دهند و نتایج سریع تری را تجربه کنند.BPM ایجاد، بهینه سازی، اجرا و ارزیابی فرآیندهای خاص در یک سازمان است.نظم BPM را می توان برای فعالیت های عملیاتی که تکراری، مداوم و قابل پیش بینی هستند به کار برد. با BPM، سازمان‌ها می‌توانند این فعالیت‌ها را ساده‌سازی کنند تا تیم‌هایشان بتوانند به نقاط عطف تجاری دست یابند، هزینه خطا را کاهش دهند و تجربیات عالی برای مشتری ارائه دهند.BPM می تواند به سازمان ها در دستیابی به اهداف تجاری در بخش ها و عملکردهای مختلف کمک کند. این شامل:· حساب‌های پرداختنی و دریافتنی: تسریع در بررسی و تأیید فاکتورها، کاهش تأخیر پرداخت‌ها با نظارت قابل مشاهده و پیگیری آسان‌تر· منابع انسانی (HR): استخدام کارکنان جدید، خودکار کردن مسیریابی اسناد· انطباق و مدیریت ریسک: شناسایی ریسک های قانونی و مالی، اطلاع رسانی به تیم های حسابرسی داخلی برای پیگیری و حل مسائلسامانه مدیریت قوانین کسب و کار یا BRMS :Business Rule Manager تیم‌های فناوری اطلاعات را قادر می‌سازد تا منطق تجاری پنهانی را که رفتار برنامه را هدایت می‌کند، کشف کنند. با در نظر گرفتن این قوانین تجاری، تحلیلگران و مدیران می توانند اطمینان حاصل کنند که این سیستم ها همانطور که انتظار می رود یا طبق مقررات یا صنعت اداره می شوند، عمل می کنند. تیم های توسعه همچنین می توانند ارزش قوانین تجاری اثبات شده را با استفاده مجدد از آنها در معماری وب یا میکروسرویس ها افزایش دهند.چالش کسب و کاربرنامه هایی که کسب و کار شما را اجرا می کنند به طور قابل ملاحظه ای سفارشی شده اند تا از نیازهای منحصر به فرد شما پشتیبانی کنند. این "منطق تجاری" تخصصی رفتار سازمان شما را کنترل می کند و شما را از رقبای خود متمایز می کند. بنابراین این قوانین تعبیه شده در برنامه های شما دارایی های مهم تجاری هستند که باید درک، مدیریت و استفاده مجدد شوند.با این حال، چالش این است که قوانین تجاری اغلب در میلیون ها خط کد مدفون می شوند. هیچ سند فعلی برای کمک به درک این سیستم ها وجود ندارد. علاوه بر این، خود قوانین اغلب با ورود درخواست‌های تغییر اصلاح و تکرار می‌شوند. این منجر به موارد زیر می‌شود:· ناتوانی در انطباق: وقتی کاربران تجاری می خواهند فرآیندها را تطبیق دهند یا پیشنهادات جدیدی اضافه کنند، باید منطق برنامه ها را تغییر دهند، اما بینش محدود در قوانین کسب و کار شما مانع این تغییر می شود.· حکمرانی ضعیف: ممیزی های داخلی و مقررات دولتی ایجاب می کند که بر رفتار شرکت خود کنترل داشته باشید، که مستلزم درک قوانین کسب و کارتان است.· نیاز به مدرن سازی: منطق کسب و کار شما دارایی ارزشمندی است که برای حمایت از استراتژی های شرکت شما اصلاح شده است. باید اطمینان حاصل کنید که این منطق می تواند در صورت امکان مجدداً مورد استفاده قرار گیرد و برای پشتیبانی از یک رویکرد API محور یا سرویس گرا انعطاف پذیر گسترش یابد.صف پیام :صف پیام پیام ها را به صورت ناهمزمان حمل و تحویل می دهد. صف های پیام نیز به طور گسترده در معماری های رویداد محور استفاده می شود، جایی که عملیات خاصی پس از دریافت پیام از یک سرویس خارجی انجام می شود. صف های پیام راهی برای انتقال پیام برای راه اندازی این سرویس ها هستند. از آنجایی که این سرویس پس از وقوع یک رویداد کار می کند، معماری مبتنی بر رویداد نامیده می شود.صف پیام چیست؟صف پیام نوعی سیستم نرم افزاری است که امکان ارسال و دریافت پیام بین برنامه های مختلف را فراهم می کند. این روشی را برای ارسال پیام‌ها به یک برنامه به صورت ناهمزمان فراهم می‌کند، به این معنی که نیازی نیست قبل از ارسال پیام بعدی منتظر پاسخ بمانید.صف های پیام برای ارتباط بین سیستم ها، برنامه ها و سرویس ها استفاده می شود. آنها یک زیرساخت پیام رسانی را فراهم می کنند که تبادل ناهمزمان پیام ها را بین سیستم ها امکان پذیر می کند و فرستنده را از گیرنده جدا می کند.یک شکل ناهمزمان از ارتباط که در آن یک برنامه یا شخص پیامی را به برنامه یا شخص دیگری ارسال می کند، اما منتظر پاسخ یا تأیید فوری نیست.داکر و کانتینرسازی :پلتفرم Docker به شما امکان می دهد برنامه(های) خود را بسته بندی کنید و آنها را بدون هیچ گونه وابستگی به ابر تحویل دهید. اگر شروع به ایجاد برنامه های کاربردی مبتنی بر ابر کرده اید، باید درک قوی از مزایای Docker داشته باشید. این پلتفرم یک راه عالی برای ایجاد محیط های ایزوله و کوچک کردن خودکار آنهاست.فلسفه ما ایجاد سیستم هایی است که بر توسعه یک برنامه واحد متمرکز هستند. منظورم این است که ما می خواهیم با یک یا شاید دو پروژه منحصر به فرد کار کنیم و اجازه دهیم بقیه برنامه های ما به ابر منتقل شوند. ما تمایل داریم این برنامه ها را به اجزای ایزوله و کپسوله ای تقسیم کنیم که منابع مشترکی ندارند. این فرآیند تقسیم یک Dockerfile و یک تعریف ساخت مبتنی بر برنامه ایجاد می کند که با استفاده از ابزارهایی مانند Docker Compose مستقر می شود.در حالی که ما معمولاً یک برنامه واحد را بر روی پلتفرم Docker می‌سازیم، این بدان معنا نیست که نمی‌توانید چندین برنامه داشته باشید که هر کدام دارای مخازن کد هستند. برنامه‌های موجود در پشته برنامه ما نیازی به ساخت و استقرار دقیق ندارند. به عنوان مثال، ما می توانیم یک سیستم معماری میکروسرویس توسط خودمان ایجاد کنیم. از کانتینرهای Docker (با تصاویر استاندارد Docker که می‌بینید اشتباه گرفته نشود) برای بسته‌بندی خدمات خود و استقرار آنها در ارائه‌دهندگان ابری مانند AWS، Google Cloud، Azure و غیره استفاده می‌کند. مزایای Docker در ساخت و استقرار برنامه‌ها بسیار زیاد است :· ذخیره یک دسته از کانتینرها· به اشتراک گذاری منابع انعطاف پذیر· مقیاس پذیری - بسیاری از کانتینرها را می توان در یک میزبان قرار داد· سرویس خود را روی سخت افزاری اجرا کنید که بسیار ارزان تر از سرورهای استاندارد است· استقرار سریع، سهولت ایجاد نمونه‌های جدید و مهاجرت سریع‌تر.· سهولت جابجایی و نگهداری برنامه های کاربردی شما· امنیت بهتر، دسترسی کمتر مورد نیاز برای کار با کدهای در حال اجرا در داخل کانتینرها، و وابستگی کمتر نرم افزاریهنگام ایجاد زیرساخت کانتینری لازم برای ساخت برنامه های کاربردی در فضای ابری، این مزایای Docker را در نظر داشته باشید. فلسفه ما شامل استفاده از کانتینرهای Docker برای بسیاری از برنامه هایمان است به جای ساختن هر برنامه و توزیع جداگانه برنامه همانطور که ممکن است با Heroku، CloudFront، Google App Engine و غیره.ارکستر کانتینر :Kubernetes (همچنین به عنوان "K8s" شناخته می شود) یک سیستم ارکستراسیون کانتینر منبع باز برای خودکار کردن استقرار، مقیاس بندی و مدیریت برنامه های کاربردی کانتینری است. در ابتدا توسط گوگل توسعه داده شد و اکنون توسط بنیاد محاسبات بومی ابری (CNCF) نگهداری می شود. Kubernetes به سرعت تبدیل به استاندارد واقعی برای ارکستراسیون کانتینر شده است و توسط شرکت هایی مانند Uber، Dropbox و Salesforce برای مدیریت حجم کاری تولید خود استفاده می شود. در این مقاله، ما مقدمه ای از Kubernetes، از جمله ویژگی های کلیدی و نحوه عملکرد آن را ارائه خواهیم کرد.Kubernetes روشی مبتنی بر پلتفرم برای استقرار و مدیریت برنامه‌های کاربردی کانتینری در یک محیط خوشه‌ای ارائه می‌کند. توزیع و زمان‌بندی کانتینرها را در میان دسته‌ای از گره‌ها خودکار می‌کند و ویژگی‌های بسیاری را برای اطمینان از در دسترس بودن و انعطاف‌پذیری برنامه‌های شما فراهم می‌کند.Kubernetes چگونه کار می کند؟در سطح بالایی، Kubernetes با انتزاع زیرساخت های زیربنایی و ارائه یک روش یکسان برای استقرار و مدیریت برنامه های کاربردی کانتینری کار می کند. این از طریق ترکیبی از API ها، ابزارهای خط فرمان و فایل های پیکربندی اعلامی به دست می آید.واحد اصلی استقرار در Kubernetes کانتینر است که یک بسته سبک وزن، مستقل و قابل اجرا است که شامل همه چیزهایی است که برای اجرای یک برنامه نیاز است (مانند کد، کتابخانه ها، وابستگی ها). کانتینرها از یکدیگر و از سیستم عامل میزبان جدا شده اند و به کارگیری و مدیریت آنها را آسان می کند.در Kubernetes، کانتینرها در واحدهای منطقی به نام pods سازماندهی می شوند. یک pod گروهی از یک یا چند کانتینر است که با هم در یک گره مستقر شده اند و فضای نام شبکه یکسانی را به اشتراک می گذارند. Pods کوچکترین واحدهای قابل استقرار در Kubernetes هستند و برای میزبانی برنامه ها استفاده می شوند.خوشه‌های Kubernetes از تعدادی گره تشکیل شده‌اند که ماشین‌های فیزیکی یا مجازی هستند که زمان اجرا و میزبان Kubernetes را اجرا می‌کنند. گره‌ها توسط صفحه کنترل Kubernetes مدیریت می‌شوند، که مسئول زمان‌بندی پادها، اطمینان از عملکرد صحیح آنها و انجام کارهای دیگر مانند مقیاس‌بندی و خوددرمانی است.علاوه بر پادها و گره‌ها، Kubernetes شامل تعدادی مؤلفه دیگر نیز می‌شود، مانند سرویس‌ها، که نقطه پایانی شبکه پایداری را برای گروهی از پادها فراهم می‌کند، و حجم‌های پایدار، که به برنامه‌ها اجازه می‌دهد تا داده‌ها را حتی اگر پادهایی که روی پادها در حال اجرا هستند ذخیره کنند. خاتمه می یابند.برخی از ویژگی های ارائه شده توسط Kubernetes عبارتند از:· استقرار و مقیاس بندی برنامه های کاربردی کانتینری· متعادل کننده بار و خود ترمیمی برنامه ها· مدیریت پیکربندی و مدیریت مخفی· تخصیص منابع و سهمیه بندی· کشف سرویس و تعادل بارKubernetes اغلب همراه با فناوری‌های کانتینری‌سازی مانند Docker استفاده می‌شود و به‌عنوان راهی برای استقرار و مدیریت برنامه‌های مبتنی بر میکروسرویس‌ها به طور فزاینده‌ای محبوب می‌شود.ابزار مدیریت لاگ ELK :ELK Stack مجموعه‌ای از سه محصول منبع باز - Elasticsearch، Logstash و Kibana است. پشته ELK برای شناسایی مشکلات سرورها یا برنامه‌ها، ورود به سیستم متمرکز را فراهم می‌کند. این به شما امکان می دهد تمام سیاهههای مربوط را در یک مکان جستجو کنید. همچنین با اتصال گزارش‌ها در یک بازه زمانی خاص به یافتن مشکلات در چندین سرور کمک می‌کند.· E مخفف ElasticSearch: برای ذخیره سیاههها استفاده می شود· L مخفف LogStash است: برای حمل و نقل و همچنین پردازش و ذخیره گزارش استفاده می شود.· K مخفف Kibana است: یک ابزار تجسم (واسط وب) است که از طریق Nginx یا Apache میزبانی می شود.ElasticSearch، LogStash و Kibana همگی توسط شرکتی به نام Elastic توسعه، مدیریت و نگهداری می شوند.ELK Stack طوری طراحی شده است که به کاربران امکان می دهد داده ها را از هر منبع و در هر قالبی دریافت کنند و آن داده ها را در زمان واقعی جستجو، تجزیه و تحلیل و تجسم کنند.ابزارهای مانیتورینگ مانند prometheus :مستقیماً از منبع، "Prometheus یک جعبه ابزار نظارت و هشدار سیستم های منبع باز است..."این بیانیه دقیق است اما واقعاً به مقیاسی که Prometheus به عنوان ابزار منبع باز واقعی برای جمع‌آوری معیارها و ایجاد هشدارهای اساسی در دنیای مبتنی بر ابر امروزی دست یافته است، نمی‌پردازد. این امر مخصوصاً اگر در جهان Kubernetes هستید که در آن یک واقعیت غیرقابل انکار است که Prometheus Data پادشاه است، صادق است.معیارهای Prometheus از ذخیره‌گاه داده‌های خودش می‌آید که از آن برای جمع‌آوری داده‌های سری زمانی که از معیارهایی که نظارت می‌کند تولید می‌کند، استفاده می‌کند. Prometheus همچنین دارای مجموعه گسترده ای از پلاگین های موجود است که به آن امکان می دهد داده ها را در معرض راه حل های مختلف خارجی قرار دهد و داده ها را از هر تعداد منبع داده دیگر، از جمله چندین راه حل نظارت بر ابر عمومی، وارد کند. AWS حتی Prometheus را برای ارائه EKS (Kubernetes) خود از طریق سرویس CloudWatch خود توصیه می کند.نظارت پرومتئوس محدودیت‌هایی دارد که در حول و حوش مدیریت داده‌ها و متریک با مقیاس‌پذیری رخ می‌دهد. برای مثال، اگر نیاز به کاهش مقیاس یک نمونه Kubernetes وجود داشته باشد، انتخاب‌های مربوط به نحوه مقیاس‌سازی تأثیر زیادی بر نحوه ذخیره داده‌های آن نمونه خواهد داشت. علاوه بر این، این امر می‌تواند جمع‌آوری این داده‌ها را برای بازگرداندن دیدگاهی جامع از نظارت Kubernetes دشوار کند. هنگامی که پیکربندی استاندارد به محدودیت های خود رسید، دو رویکرد اصلی وجود دارد. اینها باید یک سری از گره های کارگری داشته باشند که داده ها را برای مدیریت حجم تقسیم می کنند، یا Prometheus را برای داشتن چندین نمونه مستقل تقسیم می کنند. سناریوی بخش‌بندی‌شده به ابزار اضافی برای بازگرداندن آن دیدگاه جامع نیاز دارد. مانند فدرال‌سازی نمونه‌ها از طریق یک نمونه «جهانی»، که در آن راه‌حل‌های تجاری مانند Sumo Logic مقیاس‌پذیری را در پشت صحنه مدیریت می‌کنند.به عنوان یک نکته جانبی، اگر از سری مدل استقرار گره‌های کارگر برای کمک به مقیاس‌پذیری با پیچیدگی استقرار ذاتی آن استفاده شود، همچنین یک مشکل پایداری داده ذاتی را حل می‌کند که در آن Prometheus ترجیح می‌دهد از ذخیره‌سازی محلی استفاده کند. این ترجیح برای ذخیره سازی محلی به این معنی است که اگر یک گره یک تصادف مرگبار داشته باشد، تمام داده های فعلی و تاریخی آن گره برای اکثر استقرارهای Prometheus از بین می رود.Prometheus دارای قابلیت‌های تجسم اولیه است که می‌توان از آن‌ها استفاده کرد اگر بخواهید تعداد انگشت شماری از معیارها را برای مشاهده روندهای اساسی در معرض دید قرار دهید، اما تقریباً همه سازمان‌ها داده‌ها را در معرض مجموعه تجسم قدرتمندتری قرار می‌دهند.Prometheus همچنین می تواند با استفاده از یک ظرف Docker اجرا شود. با این حال، معمولاً به عنوان یک مستقل مستقر نمی شود. اغلب در یک خوشه Kubernetes استفاده می شود و با استفاده از نمودار Helm یا مدیریت یک اپراتور به کار می رود. این دو روش استقرار بسیاری از پیچیدگی‌های ذاتی اجرای در یک خوشه Kubernetes را برطرف می‌کنند و به Prometheus اجازه می‌دهند به بهترین چیزی که در معرض نمایش و جمع‌آوری معیارها از pods در خوشه است، پایبند بماند.تجزیه و تحلیل کد استاتیک :تجزیه و تحلیل کد استاتیک، تجزیه و تحلیل نرم افزار کامپیوتری است که بدون اجرای واقعی کد انجام می شود. ابزارهای تجزیه و تحلیل کد استاتیک تمام کدهای یک پروژه را اسکن می کنند و آسیب پذیری ها را جستجو می کنند، کد را در برابر بهترین شیوه های صنعت تایید می کنند و برخی از ابزارهای نرم افزاری بر اساس مشخصات پروژه خاص شرکت اعتبار سنجی می کنند. ابزارهای تجزیه و تحلیل کد استاتیک توسط تیم های توسعه نرم افزار و تضمین کیفیت برای اطمینان از کیفیت و امنیت کد و برآورده شدن الزامات پروژه استفاده می شود. تجزیه و تحلیل کد استاتیک یک نوع مدیریت کد منبع است و می تواند با سیستم های کنترل نسخه و از طریق کارهای اتوماسیون ساخت با استفاده از نرم افزار یکپارچه سازی مداوم یکپارچه شود.برای واجد شرایط شدن به عنوان یک ابزار تجزیه و تحلیل کد استاتیک، یک محصول باید:· کد را بدون اجرای آن کد اسکن کنید· آسیب پذیری های امنیتی را پس از اسکن لیست کنید· کد را در برابر بهترین شیوه های صنعت اعتبار سنجی کنید· توصیه هایی در مورد مکان و نحوه رفع مشکلات ارائه دهیدSonarQube ابزار پیشرو برای بازرسی مداوم کیفیت کد و امنیت کد و هدایت تیم های توسعه در طول بررسی کد است. SonarQube برای 27 زبان راهنمایی روشنی برای اصلاح ارائه می کند تا توسعه دهندگان بتوانند مشکلات را درک و برطرف کنند و بنابراین تیم ها می توانند نرم افزار بهتر و ایمن تری ارائه دهند. SonarQube در گردش کار شما ادغام می شود تا بازخورد مناسب را در زمان مناسب ارائه دهد: در IDE با SonarLint، در درخواست های کششی و در خود SonarQube. SonarQube با بیش از 225000 استقرار برای کمک به تیم‌های توسعه کوچک و سازمان‌های جهانی، ابزاری را برای تیم‌ها و شرکت‌ها در سراسر جهان فراهم می‌کند تا بر کیفیت کد و امنیت کد خود تأثیر بگذارند.تحویل پیوسته :تحویل مداوم فرآیند مهم ارائه نرم افزار/به روز رسانی ها به تولید در مراحل کوچکتر است، که اطمینان حاصل می کند که نرم افزار می تواند در هر زمان منتشر شود. با این رویکرد DevOps، تیم همیشه آماده «تحویل در هر زمان» به تولید خواهد بود.بنابراین، تحویل پیوسته یک خط لوله یا چرخه حیات یک کد است که در آن کدی که به تازگی توسط تیم نرم افزاری توسعه یافته یا به روز شده است، در مراحل مختلف هم از طریق تست های دستی و هم از طریق تست های خودکار آزمایش می شود و هم از گیت های مرحله دستی و هم خودکار عبور کرده و وارد می شود. تولیدتمرکز و هدف اصلی تحویل مداوم، ساخت، آزمایش و عرضه به مشتری بسیار سریعتر و بیشتر در چرخه های کوتاه است.در زیر مزایای سی دی آورده شده است.· تعداد تحویل را افزایش می دهد.· خطر شکست در تولید را به حداقل می رساند.· کار دستی را کاهش می دهد.· اعتماد به نفس در تیم را افزایش می دهد.· تیم را قادر می سازد تا همه چیز را خودکار کند.· بازخورد سریعتر را فعال می کند.SSO چیست :SSO یک سرویس مجوز جلسه و کاربر است که به کاربران اجازه می‌دهد از یک مجموعه از اعتبارنامه‌های ورود مانند نام کاربری و رمز عبور برای دسترسی به چندین برنامه مستقل استفاده کنند. به عبارت دیگر، مجوز بین چندین سرویس را فراهم می کند. تحت رویکرد مدیریت هویت فدرال (FIM) قرار می‌گیرد که چارچوبی را فراهم می‌کند که در آن یک سرور سیاست SSO جداگانه از روند ورود مراقبت می‌کند و اطلاعات سرویس شخص ثالث را در مورد کاربر بدون افشای رمز عبور کاربر ارسال می‌کند.سرویس مش :مش سرویس یک لایه زیرساخت قابل تنظیم و با تأخیر کم است که برای مدیریت حجم بالایی از ارتباطات بین فرآیندی مبتنی بر شبکه در میان خدمات زیرساخت برنامه با استفاده از رابط های برنامه نویسی برنامه (API) طراحی شده است. هر بخش از یک برنامه که "سرویس" نامیده می شود، به سایر خدمات متکی است تا به کاربران آنچه می خواهند بدهد. اگر یک کاربر برنامه خرده‌فروشی آنلاین بخواهد چیزی بخرد، باید بداند که آیا کالا موجود است یا خیر. بنابراین، سرویسی که با پایگاه داده موجودی شرکت ارتباط برقرار می کند، باید با صفحه وب محصول ارتباط برقرار کند، که خود باید با سبد خرید آنلاین کاربر ارتباط برقرار کند.این نوشته مربوط به بخشی از تمرینات معماری نرم افزار بهشتی می باشد. مهدی صالحی مهدی صالحی Sat, 04 Feb 2023 20:54:10 +0330 https://virgool.io/@mr.mahdi361/%D9%85%D8%A4%D9%84%D9%81%D9%87-%D9%88-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-sso-%D8%AF%D8%B1-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%D9%87%D8%A7%DB%8C-%D8%A8%D8%B2%D8%B1%DA%AF-x12ox5q75kxf 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 های این سیستم ها نگاشت برقرار می کند.https://www.sans.org/reading-room/whitepapers/authentication/secure-implementation-enterprise-single-sign-on-product-organization-1520Component های 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.pdfhttp://www.rcgglobalservices.com/blog/the-future-of-single-sign-on-belongs-to-openid-connecthttps://www.pingidentity.com/content/dam/pic/downloads/resources/white-papers/en/openid-connect-white-paper.pdf?id=b6322a80-f285-11e3-ac10-0800200c9a66استاندارد 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%20PracticesBest 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 Connect2- مدیریت Session برای پروتکل OpenId Connect3- Federated SSO از طریق پروتکل های SAML2 و OpenId Connect4- Enterprise SSO برای برنامه هایی چون Microsoft Office 365، Microsoft Sharepoint، Microsoft Dynamics و Microsoft Exchangeدسته دوم، امکانات خاص انجام عمل Authentication – به مجموعه این ویژگی ها در ادبیات SSO ، Strong Authentication گفته می شود:1- پشتیبانی از Authentication چند مرحله ای2- پشتیبانی از Windows Authentication3- پشتیبانی از X509 Authentication4- و روش های پیشرفته دیگر 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 و WSO2http://stackoverflow.com/questions/14521397/forgerock-identity-management-solution-vs-wso2-identity-serverمقایسه بین OpenAM و Gluuhttps://www.gluu.org/blog/the-gluu-server-vs-openam-opensso/مقایسه ای بین KeyCloak و WSO2http://lists.jboss.org/pipermail/keycloak-user/2016-August/007281.htmlمعیار مهم برای انتخاب محصول SSO باید داکیومنتیشن های موجود برای محصول باشد زیرا بدون مستندات موجود پیکربندی محصولات SSO امکان پذیر نیست زیرا اکثر این محصولات حول مفاهیم Security پیاده سازی شده اند و بدون مستندات کافی کار با این محصولات بسیار دشوار است.WSO2 پروتکل هایی که ساپورت می کند:OpenId and OpenId ConnectSAML v2 ProtocolKerberos KDCWSO2 واسط کاربری دارد که نقطه ی قوت آن محسوب می شود ولی مشکلی که فعلا در مورد آن وجود دارد این است که 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?wsdlWSO2، Federated Login را پشتیبانی می کند. برخی از IdP های معروفی که WSO2 با آنها integerate می شوند عبارتند از :Facebook, Microsoft, Google, Twitter, Yahoo, “Every IdP which supports SAML2 and OpenId Connect”KeyCloakپروتکل هایی که ساپورت می کند:OpenId ConnectSAML ProtocolOAuth2 ProtocolKeyCloak محصولی از 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 با آدرس زیر مراجعه کنید:https://keycloak.gitbooks.io/authorization-services-guide/content/v/2.3/topics/overview/terminology.htmlامکان دیگری که 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پروتکل هایی که ساپورت می کند:OpenId ConnectSAML v2 Protocolگلوو هم از جمله IdP های Linux-base است. یکی از مشکلات Gluu نداشتن Distribution ویندوز است. مشکل اصلی Gluu Server عدم پشتیبانی از مفهوم Realm است.https://wikis.forgerock.org/confluence/display/openam/Use+OpenAM+RESTful+ServicesOpenAM (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/https://www.ibm.com/developerworks/community/blogs/mobileblog/entry/four_things_you_need_for_your_mobile_single_sign_on_solution?lang=enچگونگی پیاده سازی 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 استفاده کرد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.#معماری_نرم_افزار_بهشتی مهدی صالحی مهدی صالحی Wed, 01 Feb 2023 20:37:51 +0330