ورود یکپارچه از نگاه سه برنامه متفاوت
فرض کنید یک سازمان سامانه تیکت، پرتال مشتری و ابزار گزارش داخلی دارد. کاربر برای هر کدام حساب جدا ساخته و تغییر سمت او باید در چند محل اعمال شود. تیم فناوری اطلاعات می خواهد ورود را یکپارچه کند، اما برنامه ها هنوز مسئول تصمیم درباره دسترسی به داده های خود هستند. Keycloak یک سامانه متن باز مدیریت هویت و دسترسی است که می تواند احراز هویت، مدیریت کاربران و ارتباط با ارائه دهندگان هویت را متمرکز کند. موفقیت پروژه به طراحی ارتباط این مرکز با برنامه ها وابسته است.
معرفی رسمی Keycloak از ورود یکپارچه، احراز هویت قوی، مدیریت کاربر، پیوند با منابع هویت و امکانات مجوزدهی نام می برد. این قابلیت ها باید متناسب با سناریو انتخاب شوند. برای مثال، انتقال صفحه ورود به یک مرکز مشترک به خودی خود تعیین نمی کند کاربر کدام پرونده مشتری را ببیند. برنامه همچنان باید هویت معتبر را به قواعد کسب و کار خود مرتبط کند. تمایز میان شناخت کاربر و اجازه انجام عملیات، پایه یک استقرار قابل دفاع است.
مرزهای هویت را پیش از ساخت حساب تعیین کنید
در Keycloak مفهوم realm برای جداسازی مجموعه ای از کاربران، تنظیمات و برنامه های متصل به کار می رود. تصمیم درباره تعداد این محدوده ها را بر اساس مرز مدیریتی و نیاز جداسازی بگیرید. ساخت یک محدوده برای هر برنامه ممکن است هدف ورود مشترک را پیچیده کند. قرار دادن همه محیط ها در یک محدوده نیز می تواند تغییر آزمایشی را به تولید نزدیک کند. باید روشن باشد چه تیمی مدیر هر محدوده است و چه چیزی میان آنها مشترک خواهد بود.
برای مثال، محیط آزمون بهتر است با هویت ها و تنظیمات مستقل قابل آزمایش باشد. اگر توسعه دهنده برای امتحان جریان ورود به حساب واقعی مشتری نیاز پیدا کند، طراحی محیط ناقص است. داده نمونه، دامنه آزمایشی و برنامه ثبت شده جداگانه امکان بررسی خطا را فراهم می کنند. در گزارش آزمون، نام محدوده و شناسه برنامه را بنویسید تا نتیجه ای که روی محیط آزمایش دیده شده به اشتباه تأیید تولید تلقی نشود.
مدل نام گذاری حساب ها نیز اهمیت دارد. نام نمایشی، نشانی ایمیل و شناسه پایدار کاربر نقش یکسانی ندارند. ایمیل ممکن است تغییر کند و دو منبع هویت ممکن است نام های مشابه داشته باشند. برنامه باید برای پیوند دادن داده های خود به هویت، از شناسه و قرارداد مشخص استفاده کند. تغییر ایمیل یک کارمند نباید ناخواسته به ساخت یک مشتری تازه یا انتقال دسترسی حساب دیگری منجر شود.
هر برنامه یک قرارداد اتصال دارد
در اتصال مبتنی بر OpenID Connect، برنامه به عنوان client ثبت می شود و نشانی های بازگشت، جریان ورود و نحوه دریافت توکن تنظیم می شوند. این تنظیمات بخشی از مرز امنیتی هستند. نشانی بازگشت باید به مقصدهای مورد انتظار محدود شود و با مسیر واقعی برنامه هماهنگ باشد. الگوهای بسیار باز ممکن است آزمایش اولیه را ساده کنند، اما بازبینی و کنترل مقصد را دشوار خواهند کرد.
نوع برنامه در انتخاب روش اتصال اثر دارد. یک سرویس سمت سرور می تواند برخی اطلاعات محرمانه را در محیط کنترل شده نگه دارد، در حالی که کد مرورگر یا برنامه توزیع شده چنین فرضی ندارد. مستندات اتصال مناسب همان نوع برنامه را دنبال کنید و راز سمت سرور را در فایل جاوااسکریپت قرار ندهید. مرورگر و برنامه موبایل مرز اعتماد متفاوتی دارند و نباید صرف شباهت صفحه ورود با تنظیمات یکسان راه اندازی شوند.
پس از دریافت توکن، برنامه باید اعتبار آن را مطابق کتابخانه و پروتکل انتخاب شده بررسی کند. صادرکننده، مخاطب، امضا و زمان اعتبار به هویت قابل استفاده معنا می دهند. خواندن نام کاربر از یک رشته رمزگشایی شده بدون اعتبارسنجی، تأیید هویت محسوب نمی شود. بهتر است از کتابخانه نگهداری شده و راهنمای رسمی استفاده شود و آزمون توکن نامعتبر نیز در کنار ورود موفق قرار گیرد.
نقش ها را به عملیات واقعی وصل کنید
نقش هایی مانند پشتیبان، مدیر مالی و مشاهده گر باید با عملیات مشخص برنامه ارتباط داشته باشند. اگر نقش مدیر در سامانه تیکت با همان نام در گزارش مالی استفاده می شود، لازم است معلوم باشد آیا معنای یکسان دارد. نام مشترک بدون قرارداد می تواند دسترسی ناخواسته ایجاد کند. نقش های مخصوص برنامه و نقش های سازمانی را به گونه ای طراحی کنید که مالک و دامنه هر کدام روشن بماند.
در مثال پرتال مشتری، داشتن نقش کاربر برای دیدن همه پرونده ها کافی نیست. برنامه باید تعلق هر پرونده به همان مشتری یا سازمان را نیز بررسی کند. اطلاعات هویتی می تواند ورودی این تصمیم باشد، اما کنترل روی منبع داده در خود برنامه باقی می ماند. آزمون دو حساب از دو مشتری متفاوت، به ویژه هنگام استفاده از شناسه مستقیم پرونده در نشانی، بخش مهمی از تأیید اتصال است.
گروه بندی کاربران می تواند مدیریت را ساده کند، اما تغییر عضویت گروه باید با چرخه منابع انسانی هماهنگ باشد. خروج کارمند، تغییر تیم و دسترسی موقت پیمانکار رویدادهای متفاوتی هستند. برای دسترسی موقت تاریخ پایان و مالک تأییدکننده تعیین کنید. یک گزارش دوره ای از گروه های پرقدرت و اعضای آنها، خطاهای تدریجی را زودتر نشان می دهد و وابستگی به حافظه مدیر سامانه را کاهش می دهد.
عامل دوم و بازیابی باید با هم طراحی شوند
فعال کردن عامل دوم زمانی کامل است که ثبت اولیه، تغییر دستگاه و بازیابی حساب نیز مشخص باشند. کاربری که تلفن خود را از دست داده باید راه تأییدشده ای برای بازگشت داشته باشد. اگر میز کمک با یک تماس ساده همه کنترل ها را حذف کند، کیفیت مسیر بازیابی از صفحه ورود مهم تر می شود. برای حساب های پرقدرت، سطح تأیید درخواست و ثبت تصمیم باید متناسب با اثر دسترسی باشد.
جریان ورود را ابتدا روی گروه محدودی آزمایش کنید. دستگاه های مختلف، مرورگرهای رایج، نشست منقضی و ساعت ناهماهنگ را پوشش دهید. پیام خطا باید به کاربر کمک کند بدون افشای جزئیات غیرضروری درخواست پشتیبانی بدهد. مسئول میز کمک نیز باید بداند کدام اطلاعات تشخیصی را بگیرد و چه چیزی، مانند کد یک بار مصرف یا رمز کاربر، نباید درخواست شود.
دسترسی اضطراری مدیران را پیش از اجباری کردن تنظیمات جدید بررسی کنید. ممکن است یک تغییر نادرست همه حساب های مدیریتی عادی را از ورود بازدارد. روش بازیابی باید محدود، ثبت شدنی و آزموده باشد. وجود حساب اضطراری به معنی استفاده روزمره از آن نیست. پس از هر استفاده، علت، تغییر انجام شده و بازگرداندن شرایط عادی را ثبت کنید تا این مسیر به نقطه مبهم مدیریت تبدیل نشود.
نشست و خروج را از دید کاربر آزمایش کنید
کاربر انتظار دارد خروج از یک محیط رفتار مشخصی داشته باشد، اما چند برنامه ممکن است نشست های مستقل خود را نگه دارند. لازم است رابطه نشست مرکزی و نشست محلی هر برنامه بررسی شود. در آزمون، از برنامه اول خارج شوید و سپس به برنامه دوم و یک زبانه قدیمی برگردید. نتیجه را بر اساس طراحی مورد انتظار ارزیابی کنید. صرف نمایش پیام خروج در یک صفحه، پایان همه نشست ها را ثابت نمی کند.
تغییر نقش کاربر نیز باید از نظر زمان اثر بررسی شود. اگر برنامه اطلاعات نقش را تا پایان اعتبار توکن نگه دارد، حذف نقش ممکن است فوراً در همه درخواست ها منعکس نشود. این رفتار باید شناخته شده باشد تا در رخداد واقعی تصمیم مناسب گرفته شود. طول عمر نشست و توکن را با نیاز عملیاتی و ریسک دسترسی هماهنگ کنید و روش قطع دسترسی اضطراری را جدا بیازمایید.
زیرساخت هویت یک وابستگی حیاتی است
با متمرکز شدن ورود، اختلال سامانه هویت می تواند چند برنامه را هم زمان تحت تأثیر قرار دهد. ظرفیت، پایگاه داده، گواهی، زمان سیستم و اتصال شبکه باید پایش شوند. سناریوی قطع کوتاه و بازیابی را با برنامه های متصل امتحان کنید. برخی درخواست ها با نشست موجود ادامه می یابند و برخی به ورود تازه نیاز دارند. دانستن این تفاوت برای برنامه ریزی نگهداری و اطلاع رسانی به کاربران ضروری است.
پشتیبان گیری باید داده و تنظیمات لازم برای بازسازی محیط را پوشش دهد. نسخه پشتیبان بدون آزمون بازیابی، زمان بازگشت را معلوم نمی کند. در یک محیط جدا، بازیابی را اجرا و ورود یک حساب نمونه، نقش ها و اتصال یک برنامه آزمایشی را بررسی کنید. همچنین وابستگی های بیرونی مانند منبع کاربران یا ارائه دهنده هویت دیگر را در نقشه بازیابی بنویسید.
گزارش ها باید پرسش عملیاتی را پاسخ دهند
تلاش ورود ناموفق، تغییر نقش، ثبت برنامه و عملیات مدیران ارزش بررسی دارند. با این حال، حجم زیاد گزارش بدون مسئول مشخص به نتیجه نمی رسد. برای هر دسته رویداد تعیین کنید چه کسی آن را می بیند و چه شرایطی نیاز به اقدام دارد. زمان همگام و شناسه ارتباطی میان برنامه و سامانه هویت، دنبال کردن یک خطای ورود را آسان تر می کند.
گزارش حاوی داده هویتی را با دسترسی محدود نگه دارید. تیم پشتیبانی معمولاً برای بررسی خطا به کل محتوای توکن نیاز ندارد. در راهنمای عیب یابی، روش حذف اطلاعات حساس از نمونه ها را بنویسید و از انتشار آنها در تیکت عمومی جلوگیری کنید. مشاهده پذیری باید امکان تشخیص علت را بدهد، در حالی که داده کاربران فقط در اختیار افراد مسئول قرار می گیرد.
انتقال مرحله ای از حساب های پراکنده
مهاجرت را با یک برنامه کم خطر و گروه کاربری کوچک آغاز کنید. پیش از انتقال، روش پیوند حساب قدیمی با شناسه جدید را آزمایش کنید تا داده های قبلی کاربر حفظ شوند. سپس ورود، خروج، تغییر نقش، فراموشی رمز و غیرفعال کردن حساب را بررسی کنید. نتیجه هر مرحله باید شامل رفتار برنامه باشد، نه فقط موفقیت صفحه مرکزی ورود.
پس از اتصال چند برنامه، معیارهایی مانند کاهش حساب های بی صاحب، زمان لغو دسترسی و تعداد خطاهای قابل تشخیص را دنبال کنید. Keycloak زمانی به مدیریت بهتر کمک می کند که مسئولیت هویت، قرارداد برنامه ها و روند پشتیبانی روشن باشند. یک مرکز ورود با تنظیمات مستند و آزمون های واقعی، برای تیم قابل نگهداری است و به کاربر تجربه ای می دهد که رفتار آن در حالت عادی و هنگام خطا قابل فهم باشد.
