{
  "title": "مدل مجوزها و دسترسی‌ها",
  "slug": "team/backend/ADR/ADR-Backend-004",
  "url": "/docs/team/backend/ADR/ADR-Backend-004",
  "frontmatter": {
    "layout": "doc",
    "title": "مدل مجوزها و دسترسی‌ها",
    "description": "مستند تصمیم‌گیری معماری (ADR) درباره مدل کنترل دسترسی و مجوزها — جایگزین شده توسط IAM Policy Engine",
    "version": "1.1.0",
    "status": "SUPERSEDED",
    "author": "Antigravity, Backend Team",
    "owner": "Backend Team",
    "created_at": "2026-06-13",
    "updated_at": "2026-06-22",
    "tags": "",
    "reviewers": ""
  },
  "sections": [
    {
      "level": 1,
      "heading": "مدل مجوزها و دسترسی‌ها",
      "content": "**Authorization & Permission Model**\n\n> **ADR-Backend-004**\n>\n> ⚠️ **این تصمیم با ADR-Backend-004-v2 جایگزین شده است.**\n>\n> بر اساس [Blueprint سرویس IAM v1.1](../services/iam-service.md)، مدل Authorization از Ory Keto به **Policy Engine داخلی IAM** تغییر یافت.\n>\n> دلایل اصلی:\n> - کاهش وابستگی به سرویس خارجی (Keto)\n> - یکپارچگی منطق مجوزدهی در IAM\n> - سادگی معماری و استقرار\n> - حذف پیچیدگی Relation Tuples در نسخه اول\n\n---"
    },
    {
      "level": 2,
      "heading": "وضعیت",
      "content": "**Status**\n\n⚠️ **جایگزین شده (SUPERSEDED) — مطالعه [Blueprint سرویس IAM](../services/iam-service.md)**\n\n---"
    },
    {
      "level": 2,
      "heading": "تاریخ",
      "content": "**Date**\n\n2026-06-13\n\n---"
    },
    {
      "level": 2,
      "heading": "زمینه",
      "content": "**Context**\n\nپلتفرم NONS نیازمند یک مدل کنترل دسترسی منعطف، پویا و توزیع‌شده است که:\n- بتواند مقیاس‌پذیری بالا در ریزسرویس‌ها را پشتیبانی کند.\n- قوانین دسترسی را به جای کدنویسی سخت (Hardcoding)، به صورت سیاست‌های داده‌محور مدیریت کند.\n- امکان تعریف روابط پیچیده نظیر \"مالک سفارش بودن\" یا \"دسترسی مدیریت فروشگاه\" را فراهم کند.\n\nسامانه‌های سنتی مانند RBAC (نقش‌محور ساده) پاسخگوی روابط پیچیده مالکیت منابع در معماری میکروسرویس نیستند.\n\n---"
    },
    {
      "level": 2,
      "heading": "تصمیم معماری",
      "content": "**Decision**\n\nپلتفرم NONS برای پیاده‌سازی کنترل دسترسی از **Ory Keto** استفاده می‌کند. این ابزار بر پایه معماری **Google Zanzibar** کار کرده و بررسی دسترسی‌ها را بر اساس روابط (Relation-Based Access Control - ReBAC) انجام می‌دهد."
    },
    {
      "level": 3,
      "heading": "مؤلفه‌های اصلی و الگوی استقرار (D13, D15, D18):",
      "content": "1. **IAM Service:** سرویس مدیریت هویت و دسترسی‌ها که مسئولیت مدیریت نقش‌ها، سیاست‌ها و ثبت روابط در Ory Keto را دارد.\n2. **Ory Keto:** موتور بررسی دسترسی (Permission Check Engine) که به درخواست میکروسرویس‌ها پاسخ بله/خیر می‌دهد.\n3. **میکروسرویس‌های تجاری:** هر میکروسرویس برای انجام عملیات حساس روی منابع خود، از طریق فراخوانی Keto، مجوز کاربر را بررسی می‌کند.\n4. **الگوی استقرار کلاستر:** کل اجزای این لایه از طریق Helm (D15) بر روی کلاستر Kubernetes مبتنی بر K3s/K3d (D13) مستقر می‌شوند. اطلاعات اتصال به پایگاه‌های داده و رازها در فاز فعلی از طریق **Kubernetes Secrets** و در فاز آینده به وسیله **HashiCorp Vault** به کانتینرها تزریق می‌شود (D18).\n\n---"
    },
    {
      "level": 2,
      "heading": "ساختار روابط دسترسی",
      "content": "**Keto Relation Tuples**\n\nروابط در Keto به صورت چندتایی‌های رابطه (Relation Tuples) با ساختار زیر تعریف می‌شوند:\n`Namespace:Object#Relation@Subject`"
    },
    {
      "level": 3,
      "heading": "نمونه‌های کاربردی در NONS",
      "content": "**Practical Examples in NONS**"
    },
    {
      "level": 4,
      "heading": "مالکیت سفارش",
      "content": "**Order Ownership**\n\nبرای اینکه خریدار بتواند سفارش خود را مشاهده کند، رابطه زیر در زمان ایجاد سفارش در Keto ثبت می‌شود:\n`Order:order_998#owner@User:550e8400-e29b-41d4-a716-446655440000`"
    },
    {
      "level": 4,
      "heading": "دسترسی پشتیبان به داوری سفارش",
      "content": "**Dispute Arbitrator**\n\nبرای تخصیص نقش داور به یک پشتیبان روی یک اختلاف:\n`Dispute:dispute_441#arbitrator@User:889f8400-e29b-41d4-a716-446655441111`"
    },
    {
      "level": 3,
      "heading": "نحوه بررسی دسترسی",
      "content": "**Permission Checking Flow**\n\n```\n[کاربر] ──(1) درخواست عملیات روی منبع──> [میکروسرویس تجاری]\n                                                │\n                                    (2) بررسی مجوز (Check)\n                                    Namespace: Object\n                                    Relation: view / edit\n                                    Subject: User UUID\n                                                │\n                                                ▼\n                                          [Ory Keto] ──(3) پاسخ بله/خیر──> [میکروسرویس]\n```\n\n---"
    },
    {
      "level": 2,
      "heading": "پیامدها",
      "content": "**Consequences**"
    },
    {
      "level": 3,
      "heading": "پیامدهای مثبت",
      "content": "**Positive Consequences**\n\n- **دقت بالا در سطح منابع (Fine-Grained Authorization):** امکان تعریف دقیق‌ترین روابط دسترسی روی منابع منفرد.\n- **تمرکززدایی از منطق بیزینس:** میکروسرویس‌ها درگیر منطق احراز هویت و دسترسی‌های تودرتو نمی‌شوند و فقط یک سوال ساده \"آیا دسترسی دارد؟\" را از Keto می‌پرسند.\n- **پشتیبانی از ارث‌بری دسترسی‌ها:** امکان تعریف روابطی مانند \"اگر مدیر سیستم است، پس دسترسی ویرایش به تمام منابع را دارد\"."
    },
    {
      "level": 3,
      "heading": "پیامدهای منفی",
      "content": "**Negative Consequences**\n\n- **وابستگی به ابزار خارجی:** در دسترس بودن بالا (High Availability) برای Ory Keto حیاتی است زیرا گلوگاه بررسی تمامی مجوزهای سیستم است.\n- **پیچیدگی مدل ReBAC:** آموزش تیم برای کار با مفاهیم Zanzibar و مدل Relation Tuples نسبت به RBAC سنتی زمان‌بر است."
    }
  ]
}