احراز هویت و مجوزدهی
Rebati — Documentation System
Vivid Visual · ویوید ویژوال
احراز هویت و مجوزدهی
31 — Auth
- پروژه
- vivid-visual-platform
- نوع سند
- Specification
- نسخه
- 0.1
- وضعیت
- پیشنویس
محرمانه — فقط برای استفاده طرفین قرارداد
احراز هویت و مجوزدهی
Section titled “احراز هویت و مجوزدهی”معماری احراز هویت
Section titled “معماری احراز هویت”تمام جریانهای ورود با Keycloak مدیریت میشود. وب و داشبورد از OIDC Authorization Code Flow استفاده میکنند. سرویسها فقط از طریق token معتبر قابل دسترسی هستند.
مجوزدهی
Section titled “مجوزدهی”Policyها در سطح API تعریف میشوند. هر endpoint به یک یا چند permission دامنهای نگاشت میشود. Claimهای کاربر نقش، سازمان و وضعیت اشتراک را حمل میکنند.
جریانهای کاربر
Section titled “جریانهای کاربر”Student: ورود، خرید اشتراک، دسترسی Premium. Sales Agent: ورود، دسترسی CRM محدود به تیم. HR Manager: ورود با MFA اجباری و دسترسی HR کامل.
مهاجرت کاربران از WordPress به Keycloak
Section titled “مهاجرت کاربران از WordPress به Keycloak”سایت فعلی Vivid Visual روی WordPress است. کاربران در جدول wp_users و متادیتای wp_usermeta نگهداری میشوند. در پلتفرم جدید، Keycloak تنها منبع حقیقت هویت (IdP) خواهد بود.
اهداف مهاجرت هویت
Section titled “اهداف مهاجرت هویت”- حفظ حساب کاربری بر اساس ایمیل (شناسه یکتا)
- انتقال نقشهای تجاری (مشتری، مدرس، ادمین) به Role/Group در Keycloak
- حفظ دسترسی به دورهها و لایسنسهای خریداریشده پس از cutover
- عدم افشای رمز عبور خام در فرایند انتقال
استراتژی رمز عبور (دو مسیر)
Section titled “استراتژی رمز عبور (دو مسیر)”| مسیر | شرایط | تجربه کاربر |
|---|---|---|
| A — بازنشانی اجباری | پیشفرض و توصیهشده | پس از cutover، اولین ورود با «فراموشی رمز» یا ایمیل دعوت |
| B — انتقال هش | فقط اگر هش WP قابل map به Keycloak باشد | ورود با همان رمز قبلی (پیچیدگی فنی بالاتر) |
WordPress از الگوریتم phpass استفاده میکند. مسیر B نیاز به User Storage SPI یا migration script اختصاصی دارد و فقط پس از تست روی نمونه واقعی تایید میشود. در قرارداد، مسیر A بهعنوان baseline در نظر گرفته میشود.
نقشه فیلدها (WordPress → Keycloak)
Section titled “نقشه فیلدها (WordPress → Keycloak)”| منبع WP | مقصد Keycloak | توضیح |
|---|---|---|
| user_email | username + email | ایمیل نرمالشده (lowercase) |
| display_name | firstName / attribute | نام نمایشی |
| user_registered | createdTimestamp | تاریخ عضویت |
| roles (capabilities) | realm roles / groups | customer، instructor، shop_manager → نقش محصول |
| woocommerce meta | user attribute | شناسه مشتری قدیمی برای ردیابی |
| subscription status | custom claim | وضعیت اشتراک فعال/منقضی |
مراحل اجرایی
Section titled “مراحل اجرایی”- استخراج: export کاربران فعال از wp_users (حذف spam و حسابهای تست)
- پاکسازی: یکسانسازی ایمیل تکراری، ادغام حسابهای duplicate با تایید کسبوکار
- Staging import: بارگذاری در realm staging Keycloak و تست login flow
- نقشدهی: نگاشت نقش WP/WooCommerce به Groupهای Keycloak
- لینک داخلی: ذخیره legacy_user_id در PostgreSQL برای اتصال سفارش و لایسنس قدیمی
- Cutover: غیرفعال کردن login در WP، فعالسازی OIDC در وب جدید
- ارتباطات: ایمیل خوشآمدگویی + راهنمای تنظیم رمز جدید
خروجی مورد انتظار از کارفرما
Section titled “خروجی مورد انتظار از کارفرما”فایل CSV یا SQL export شامل حداقل: user_id، email، display_name، registered_at، role، وضعیت اشتراک (در صورت وجود). جزئیات فنی استخراج توسط تیم فعلی سایت یا Rebati در فاز کشف انجام میشود.
نکات اجرایی
Section titled “نکات اجرایی”session logout سراسری برای پنلها. بازبینی دورهای نقشهای غیرفعال. ثبت رخدادهای login_failure برای تحلیل امنیتی. پس از مهاجرت، wp_users فقط بهصورت آرشیو read-only نگه داشته میشود تا بازگشت اضطراری ممکن باشد.