ロールベースアクセス制御

RBAC（Role-Based Access Control）は、ユーザーをロールに割り当て、ロールに権限を付与することでアクセス制御を行う方式です。

概要

AuthrimのRBACでは以下が可能です：

• 職務や責任を表すロールの定義
• ロールへの権限割り当て
• ユーザーへの複数ロール割り当て
• global / org / resource scope での割り当て
• ロールメンバーシップに基づくアクセス評価

基本概念

ロール

ロールはユーザーに割り当て可能な権限のセットです：

{
  "id": "role-admin",
  "name": "Administrator",
  "description": "システム全体へのアクセス権限",
  "permissions": ["users:read", "users:write", "users:delete", "settings:manage"]
}

権限

権限はきめ細かなアクセス権を表します：

<リソース>:<アクション>

例：
- users:read
- users:write
- documents:delete
- settings:manage

ロール割り当て

ユーザーは複数のロールを持つことができます：

{
  "user_id": "user-123",
  "roles": [
    { "role_id": "role-admin", "scope": "global" },
    { "role_id": "role-editor", "scope": "org", "scope_target": "org-123" }
  ]
}

APIリファレンス

ロール作成

POST /api/admin/roles
Authorization: Bearer <admin_token>
Content-Type: application/json

{
  "name": "Editor",
  "description": "コンテンツを編集可能",
  "permissions": ["content:read", "content:write"]
}

ロール一覧取得

GET /api/admin/roles
Authorization: Bearer <admin_token>

ロール詳細取得

GET /api/admin/roles/{role_id}
Authorization: Bearer <admin_token>

ロール更新

PATCH /api/admin/roles/{role_id}
Authorization: Bearer <admin_token>
Content-Type: application/json

{
  "description": "コンテンツの編集と公開が可能",
  "permissions": ["content:read", "content:write", "content:publish"]
}

ロール削除

DELETE /api/admin/roles/{role_id}
Authorization: Bearer <admin_token>

ユーザーにロール割り当て

POST /api/admin/users/{user_id}/roles
Authorization: Bearer <admin_token>
Content-Type: application/json

{
  "role_id": "role-editor",
  "scope": "org",
  "scope_target": "org-123",
  "expires_at": 1735689600000
}

ユーザーからロール削除

DELETE /api/admin/users/{user_id}/roles/{assignment_id}
Authorization: Bearer <admin_token>

ユーザーのロール取得

GET /api/admin/users/{user_id}/roles
Authorization: Bearer <admin_token>

Effective permissions の取得

direct role assignment と organization membership から、ユーザーの実効権限を解決します：

GET /api/admin/users/{user_id}/effective-permissions
Authorization: Bearer <admin_token>

ロール割り当て一覧

GET /api/admin/roles/{role_id}/assignments
Authorization: Bearer <admin_token>

トークン埋め込み権限

tenant と client の claim policy が許可する場合、Authrim は token 用に role / permission claim を解決できます。管理レビューやデバッグでは上記の effective-permissions endpoint を優先してください。

ロール付きIDトークン

{
  "sub": "user-123",
  "roles": ["admin", "editor"],
  "permissions": ["users:read", "users:write", "content:read", "content:write"]
}

トークンでのロールリクエスト

スコープに roles を含めます：

GET /authorize
  ?response_type=code
  &scope=openid+profile+roles
  ...

Runtime check

service-to-service の判定には Policy Service を使います。これらの endpoint は policy worker に設定した internal policy API bearer token を要求します。

POST /policy/check-role
Authorization: Bearer <policy_api_secret>
Content-Type: application/json

{
  "subject": {
    "id": "user-123",
    "roles": [{ "name": "admin", "scope": "global" }]
  },
  "role": "admin"
}

レスポンス：

{
  "allowed": true
}

ポリシー定義

RBACポリシーはJSONで定義できます：

{
  "version": "1.0",
  "roles": [
    {
      "id": "admin",
      "name": "Administrator",
      "permissions": ["users:read", "users:write", "settings:manage"]
    },
    {
      "id": "editor",
      "name": "Editor",
      "permissions": ["content:read", "content:write", "content:publish"]
    },
    {
      "id": "viewer",
      "name": "Viewer",
      "permissions": ["content:read", "users:read"]
    }
  ]
}

権限フォーマット

custom role では users:read や content:publish のような resource:action 形式の権限を使います。system / built-in role はより広い effective permission を持つ場合がありますが、custom role 作成では明示的な permission name が検証されます。

ベストプラクティス

ロール設計

1. ロールを焦点化 - 各ロールは明確な機能を表すべき
2. ロール爆発を避ける - 細かすぎるロールを多数作成しない
3. 権限継承を使用 - 低レベルのロールを基に高レベルのロールを構築
4. ロールを文書化 - 明確な説明を含める

セキュリティ

1. 最小権限の原則 - 必要最小限の権限を割り当て
2. 定期監査 - ロール割り当てを定期的にレビュー
3. 職務分離 - 機密操作を複数のロールに分散
4. ロールライフサイクル - 未使用のロールと割り当てを削除

例：ECサイトアプリケーション

{
  "roles": [
    {
      "id": "customer",
      "permissions": ["orders:read:own", "profile:read:own", "profile:update:own"]
    },
    {
      "id": "support",
      "permissions": ["orders:read", "customers:read", "tickets:read", "tickets:write"]
    },
    {
      "id": "warehouse",
      "permissions": ["orders:read", "orders:update_status", "inventory:read", "inventory:update"]
    },
    {
      "id": "admin",
      "permissions": ["orders:read", "orders:update_status", "customers:read", "inventory:update"]
    }
  ]
}

ABACとの統合

RBACはABACと組み合わせることで、より柔軟な認可が可能になります：

{
  "effect": "allow",
  "condition": {
    "and": [
      { "role": "editor" },
      { "resource.status": "draft" }
    ]
  }
}

これにより、エディターはドラフト状態のコンテンツのみ編集可能になります。

参考資料

• NIST RBACモデル
• RFC 7662 - Token Introspection