رفتن به محتوا
زیرساخت فناوری اطلاعات

اتصال سامانه سازمانی به دولت من: ورود با دولت من در عمل چطور کار می‌کند

راهنمای فنی اتصال به دولت من برای سازمان‌ها: مستقیم یا از طریق درگاه SSO، جریان OAuth قدم به قدم، چه داده‌ای برمی‌گردد، و خطایی که بعد از راه‌اندازی خوردیم.

H
Hamze Zare Nasiri
۱ مهر ۱۴۰۵

اگر شهروند هستید و می‌خواهید وارد «دولت من» شوید، جای درست همین صفحه نیست: درگاه رسمی my.gov.ir است و ما هیچ ارتباط رسمی با آن نداریم. این مطلب برای تیم‌های فنی سازمان‌هاست؛ کسانی که می‌خواهند کارکنان یا مشتری‌هایشان با حساب دولت من وارد سامانهٔ سازمان شوند و دنبال این هستند که «اتصال به دولت من» در عمل یعنی چه.

ما در فن‌پینو ورود با دولت من را روی دو سامانهٔ واقعی راه انداخته‌ایم: فن‌کاور (سامانهٔ بیمهٔ تکمیلی کارکنان) و میز خدمت فن‌دسک برای یک دانشگاه. آنچه در ادامه می‌آید از همان پیاده‌سازی و خطاهایی است که در عمل خوردیم، نه یک توضیح کلی.

دولت من چیست و «ورود با دولت من» برای سازمان چه معنایی دارد

دولت من «پنجرهٔ ملی خدمات دولت هوشمند» است که سازمان فناوری اطلاعات آن را اداره می‌کند. شهروند یک بار با شماره موبایلی که به نام خودش ثبت شده، کد ملی و تاریخ تولد ثبت‌نام می‌کند و بعد با همان حساب به خدمات دستگاه‌های مختلف دسترسی دارد (راهنمای دیجیاتو).

برای یک سازمان، «ورود با دولت من» یعنی احراز هویت را به یک هویت ملی تأییدشده می‌سپارید. سامانهٔ شما دیگر رمز عبور نگه نمی‌دارد و نیازی به فرم ثبت‌نام، بازیابی رمز یا ارسال پیامک اختصاصی ندارد. کاربر به صفحهٔ ورود هدایت می‌شود، هویتش تأیید می‌شود و با اطلاعاتی مثل کد ملی به سامانهٔ شما برمی‌گردد.

مستقیم وصل شویم یا از یک درگاه SSO سازمانی؟

اولین تصمیم معماری همین است و معمولاً دیده نمی‌شود. دو راه وجود دارد:

  • اتصال مستقیم هر سامانه: هر نرم‌افزار جداگانه یکپارچه‌سازی را انجام می‌دهد. برای یک سامانهٔ تنها شاید کافی باشد، ولی با سومین و چهارمین سامانه هر کدام منطق ورود و نگهداری جداگانه‌ای پیدا می‌کنند.
  • یک درگاه SSO سازمانی در وسط: سازمان یک سرور احراز هویت مرکزی دارد که به دولت من وصل است، و همهٔ سامانه‌های داخلی فقط با همین درگاه با پروتکل استاندارد حرف می‌زنند. محصولاتی مثل SSO Plus دقیقاً همین مدل را می‌فروشند و از OAuth 2.0، OpenID Connect و SAML پشتیبانی می‌کنند.

در پروژهٔ ما دانشگاه از قبل درگاه SSO خودش را داشت که به دولت من متصل بود. پس فن‌کاور و فن‌دسک هیچ‌کدام مستقیم به دولت من وصل نیستند؛ هر دو یک کلاینت OAuth 2.0 معمولی برای همان درگاه دانشگاه هستند. این تفاوت مهمی است: وقتی سامانهٔ جدیدی اضافه شد، کار ما ثبت یک کلاینت تازه روی درگاه بود، نه یک یکپارچه‌سازی جدید با دولت من. اگر سازمان شما چند سامانه دارد، این مسیر تقریباً همیشه ارزان‌تر است. دربارهٔ اینکه چرا چند لاگین جدا در دانشگاه‌ها مشکل‌ساز است، این مطلب را نوشته‌ایم.

جریان ورود، قدم به قدم

درگاهی که ما به آن وصل شدیم از جریان استاندارد Authorization Code در OAuth 2.0 استفاده می‌کند. کل ماجرا چهار رفت‌وبرگشت است:

  1. هدایت به صفحهٔ ورود. کاربر روی «ورود با دولت من» می‌زند و سامانه او را به آدرس /oauth2/authorize درگاه می‌فرستد، با پارامترهای client_id، redirect_uri، response_type=code، scope=openid profile و یک مقدار تصادفی state.
  2. بازگشت با کد. بعد از تأیید هویت، کاربر به redirect_uri سامانهٔ شما برمی‌گردد و یک code یک‌بارمصرف و همان state را همراه دارد.
  3. تبادل کد با توکن، سمت سرور. سرور شما کد را همراه با client_secret به /oauth2/token می‌فرستد و توکن دسترسی می‌گیرد. این قدم هیچ‌وقت نباید در مرورگر انجام شود.
  4. گرفتن مشخصات کاربر. با توکن، مشخصات کاربر را از endpoint اطلاعات کاربر می‌گیرید و نشست محلی خودتان را می‌سازید.

چه اطلاعاتی از دولت من به سامانهٔ شما می‌رسد

این بخش به درگاه و scope شما بستگی دارد، پس فقط آنچه در اتصال خودمان دیدیم را می‌گوییم. پاسخ مشخصات کاربر شامل این فیلدها بود: کد ملی، نام، نام خانوادگی، نام پدر، شماره موبایل، جنسیت، تاریخ تولد، شماره شناسنامه، کد پستی، استان و شهر. برای بیشتر سامانه‌های سازمانی همین برای ساختن پروفایل کافی است و لازم نیست کاربر فرم پر کند.

یک توصیه: فقط چیزی را ذخیره کنید که واقعاً لازم دارید. اینکه درگاه کد پستی را می‌دهد دلیل نمی‌شود آن را در هر جدولی نگه دارید. در فن‌کاور به همین دلیل داده‌های بیمه در یک سرویس و دیتابیس جدا نگه داشته می‌شود که دلیلش را این‌جا توضیح داده‌ایم.

نکته‌های امنیتی که نباید جا بیفتد

  • state یک‌بارمصرف با انقضا. مقدار state را قبل از هدایت ذخیره کنید و در بازگشت فقط یک بار قبولش کنید. ما آن را در دیتابیس با ایندکس انقضای خودکار نگه می‌داریم تا وقتی چند پردازه یا سرور داریم هم درست کار کند؛ نگه‌داشتن در حافظهٔ یک پردازه با اولین مقیاس‌دهی خراب می‌شود.
  • client_secret فقط روی سرور. هیچ‌وقت در کد فرانت‌اند یا اپ موبایل.
  • redirect_uri دقیق. همان آدرسی که روی درگاه ثبت شده، بدون wildcard.
  • نشست محلی را امن بسازید. توکن نشست خودتان را در کوکی httpOnly و Secure بگذارید، نه در localStorage.

بزرگ‌ترین درس: دولت من می‌گوید این شخص کیست، نه اینکه اجازهٔ ورود دارد

این همان جایی است که ما خطا کردیم. احراز هویت با دولت من فقط ثابت می‌کند کسی که پشت صفحه است همان صاحب کد ملی است. اینکه آیا این شخص حق استفاده از سامانهٔ شما را دارد، سؤال دیگری است و جوابش باید از داخل سازمان بیاید.

در سامانهٔ بیمه، بعد از ورود موفق، کد ملی با فهرست پرسنل مقایسه می‌شد تا معلوم شود فرد کارمند است یا نه. آن فهرست از یک خروجی قدیمی منابع انسانی ساخته شده بود، در حالی که فهرست واقعی مشمولان بیمه را مدیران سامانه به‌روز نگه می‌داشتند. نتیجه این شد که گروهی از کارکنان واقعی، که هویتشان در دولت من کاملاً تأیید شده بود، پیام «شما کارمند دانشگاه نیستید» گرفتند.

راه‌حل این بود که منبع معتبر همان سامانه، یعنی فهرست مشمولان بیمه، هم در بررسی مجوز حساب شود تا مدیر بتواند بدون ورود دوبارهٔ فایل یا استقرار جدید، کسی را از پنل باز کند. در همان بررسی چند کد ملی نه‌رقمی هم پیدا کردیم: اکسل صفرِ اول کد ملی را به‌عنوان عدد حذف کرده بود و این افراد در مقایسهٔ دقیق رد می‌شدند.

خلاصه: قبل از اتصال به دولت من مشخص کنید کدام فهرست، در کدام سامانه، و با چه فرایندی تعیین می‌کند چه کسی اجازهٔ ورود دارد، و کد ملی را همیشه به‌صورت متن ده‌رقمی ذخیره کنید.

حساب‌های قدیمی را فراموش نکنید

اگر سامانهٔ شما از قبل کاربر داشته، روز اول ورود با دولت من یک مشکل دیگر ظاهر می‌شود. ما کاربر را با کد ملی پیدا می‌کنیم، اما بعضی حساب‌های کارشناسان قدیمی بدون کد ملی ساخته شده بودند و نام کاربری‌شان همان کد ملی بود. اگر فقط با کد ملی جست‌وجو می‌کردیم، برای این افراد حساب مشتری تازه ساخته می‌شد و دسترسی به تیکت‌هایی که به حساب واقعی‌شان ارجاع شده بود از دست می‌رفت.

راهی که جواب داد: اگر کاربری با کد ملی پیدا نشد، حساب قدیمی را از روی نام کاربری پیدا کن، کد ملی را برایش ثبت کن و فقط فیلدهای خالی را از دولت من پر کن. نقش، دسترسی‌ها و نامی که مدیر تنظیم کرده هیچ‌وقت نباید با اطلاعات ورودی بازنویسی شود.

چک‌لیست پیش از اتصال

  • اتصال مستقیم یا از طریق درگاه SSO سازمان؟ اگر درگاه دارید، از همان استفاده کنید.
  • مشخصات کلاینت (client_id، client_secret، redirect_uri) از مدیر درگاه گرفته و ثبت شده باشد.
  • منبع معتبر مجوز (چه کسی حق ورود دارد) مشخص و قابل به‌روزرسانی از داخل پنل باشد.
  • کد ملی به‌صورت رشتهٔ ده‌رقمی ذخیره و مقایسه شود.
  • نگاشت حساب‌های موجود به کد ملی پیش از فعال‌سازی بررسی شود.
  • فقط فیلدهای لازم ذخیره شوند.

پرسش‌های رایج

آیا کاربر بدون حساب دولت من می‌تواند وارد شود؟ نه از این مسیر. برای کاربرانی که حساب ندارند یا موبایلشان به نام خودشان نیست، یک مسیر جایگزین (مثلاً ورود با رمز برای حساب‌های خاص) لازم است.

آیا سامانهٔ ما رمز عبور کاربر را می‌بیند؟ خیر. کاربر روی صفحهٔ ورود درگاه احراز هویت می‌شود و سامانهٔ شما فقط کد و بعد توکن و مشخصات را دریافت می‌کند.

برای هر سامانهٔ جدید باید دوباره با دولت من یکپارچه شویم؟ اگر درگاه SSO سازمانی دارید، نه. فقط یک کلاینت جدید روی درگاه تعریف می‌شود.

اگر می‌خواهید بدانید سازمان‌ها چرا اصلاً سراغ ورود با هویت ملی می‌روند، این مطلب را هم ببینید.

سامانه‌ای برای کارکنان با ورود از طریق دولت من لازم دارید؟

فن‌کاور سامانهٔ بیمهٔ تکمیلی کارکنان است که ورودش از طریق احراز هویت ملی انجام می‌شود و به‌صورت سرویس ایزوله کنار سامانه‌های فعلی سازمان قرار می‌گیرد.

مشاهدهٔ فن‌کاور

اشتراک‌گذاری این مقاله