پرش به محتوا
Access

UserCompanyManagement (مدیریت کاربران، شرکت‌ها و دسترسی‌ها)

هویت و دسترسی

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

حوزه
زیرساخت پلتفرم / RBAC و چندمستاجری
مشتریان هدف
گروه‌های مالی با چند شرکت زیرمجموعه یا چند مستأجر مستقل؛ مدیران IT که دسترسی کارکنان را بین شرکت‌ها تفکیک می‌کنند
قابلیت‌های اصلی
مدیریت Tenant/Company/Branch، RBAC دوسطحی (Controls+UIPermissions)، ResolveUserContext، کاتالوگ دسترسی خودکار هر سرویس، TenantDatabaseMap، کش دسترسی Redis

UserCompanyManagement مالک «هویت کسب‌وکاری» پلتفرم است: پروفایل کاربران، شرکت‌ها، شعبه‌ها، عضویت کاربر در شرکت، و کل سیستم نقش و دسترسی (RBAC). این سرویس چندمستاجری (multi-tenant) طراحی شده؛ هر Tenant می‌تواند چند شرکت داشته باشد و هر شرکت به‌صورت مستقل کاربران، شعبه‌ها و دسترسی‌های خودش را دارد.

نقطهٔ کلیدی معماری آن API به‌نام ResolveUserContext است: وقتی کاربری وارد می‌شود، Identity برای ساختن claim‌های توکن (نقش‌ها، دسترسی‌ها، شرکت‌ها) این سرویس را صدا می‌زند. به همین ترتیب، TenantDatabaseMap مشخص می‌کند هر شرکت کدام دیتابیس را در هر سرویس دیگر استفاده می‌کند، که پایهٔ معماری چندمستاجری کل پلتفرم است.

سیستم دسترسی روی مدل Permission-per-UserCompany ساخته شده: هر دسترسی به رابطهٔ «کاربر در یک شرکت مشخص» تعلق دارد، نه به کاربر به‌تنهایی، یعنی یک کاربر می‌تواند در شرکت A نقش مدیر و در شرکت B نقش کارمند ساده داشته باشد. دو نوع دسترسی از هم تفکیک شده: Controls برای عملیات API (هر endpoint یک permission) و UIPermissions برای کنترل نمایش منو و صفحات در پنل. نکتهٔ مهم معماری این است که مالکیت دسترسی هر سرویس در خود همان سرویس تعریف می‌شود (نه در UserCompanyManagement)؛ هر میکروسرویس در زمان راه‌اندازی فهرست دسترسی‌های خودش را از طریق sync-service به این سرویس اعلام می‌کند و UserCompanyManagement آن را به‌عنوان کاتالوگ مرکزی نگه می‌دارد و کش می‌کند.

برای یک خریدار سازمانی این یعنی سیستمی که همزمان چند شرکت زیرمجموعه یا چند مشتری (tenant) را با مرزهای دسترسی دقیق و قابل تفکیک نگه می‌دارد، بدون این‌که افزودن سرویس یا ماژول جدید به تعریف دستی دسترسی در یک فایل مرکزی نیاز داشته باشد.

قابلیت‌ها و امکانات کلیدی

  • مدیریت چندمستاجری Tenant/Company/Branch

    هر Tenant چند شرکت و هر شرکت چند شعبه دارد؛ کاربر می‌تواند عضو چند شرکت با نقش‌های متفاوت در هرکدام باشد.

  • RBAC با دو لایهٔ Controls و UIPermissions

    Controls برای هر عملیات API و UIPermissions برای نمایش/عدم‌نمایش منو و صفحه؛ تخصیص هم در سطح نقش و هم در سطح مستقیم کاربر-شرکت.

  • ResolveUserContext برای Identity

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

  • کاتالوگ دسترسی به‌روزشونده خودکار (Permission Sync)

    هر سرویس تازه یا ماژول جدید، دسترسی‌های خودش را در startup اعلام می‌کند (sync-service)؛ ایجاد/به‌روزرسانی/حذف خودکار انجام می‌شود و دسترسی جدید به‌صورت خودکار به همهٔ کاربران SuperAdmin هم داده می‌شود.

  • ثبت‌نام عمومی و مدیریت کاربر

    مسیر ثبت‌نام عمومی موبایل بدون نیاز به JWT، به‌همراه تأیید OTP.

  • TenantDatabaseMap

    نگاشت هر شرکت به دیتابیس اختصاصی‌اش در هر سرویس، با کش ۵ دقیقه‌ای، پایهٔ جداسازی داده در معماری چندمستاجری.

  • کش دسترسی در Redis

    دسترسی هر کاربر در هر شرکت با کلید {سرویس}:permissions:{userId}:{companyId} کش می‌شود و با هر تغییر نقش/دسترسی بی‌اعتبار می‌شود.

  • تخصیص گروهی دسترسی

    اعطای دسترسی‌های یک نقش به چند کاربر-شرکت به‌صورت یک‌جا، به‌شکل افزایشی (بدون حذف دسترسی‌های قبلی).

ارزش کسب‌وکاری

جداکردن مالکیت دسترسی به خود سرویس (به‌جای تعریف دستی در یک فایل مرکزی) یعنی افزودن یک ماژول یا سرویس جدید به پلتفرم، منوها و مجوزهای لازم خودش را بدون ویرایش دستی UserCompanyManagement همراه می‌آورد؛ این ریسک فراموشی یا ناهماهنگی مجوز در پلتفرمی با ده‌ها سرویس را به‌شکل قابل‌توجهی کم می‌کند. مدل دسترسی «کاربر در شرکت» به‌جای «کاربر مطلق» برای سازمان‌هایی که چند شرکت زیرمجموعه یا مشتری مستقل دارند ضروری است، چون یک کارمند می‌تواند در یک شرکت دسترسی مدیریتی و در شرکت دیگر فقط دسترسی مشاهده داشته باشد بدون نیاز به حساب کاربری جدا.

سناریوهای استفاده

  • گروه مالی با چند شرکت زیرمجموعه که کارمندان مشترک بین برخی شرکت‌ها با نقش‌های متفاوت کار می‌کنند.
  • راه‌اندازی سریع یک مستأجر (tenant) جدید با شرکت، شعبه و کاربر ادمین اولیه، بدون دست‌کاری کد.
  • افزودن یک میکروسرویس جدید به پلتفرم که در همان روز اول، دسترسی‌های API و صفحات UI خودش را در پنل ادمین و کاتالوگ دسترسی داشته باشد.
  • بستن یا محدودکردن دسترسی یک کاربر به یک شرکت خاص بدون اثر روی عضویتش در شرکت‌های دیگر.
Get in Touch

این ماژول را روی دادهٔ نمایشی ببینید

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