コンテンツにスキップ
Authrim

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

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

概要

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

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

基本概念

ロール

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

{
  "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-admin", "role-editor"]
}

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>

ロール更新

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


{
  "name": "Editor",
  "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"
}

ユーザーからロール削除

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

ユーザーのロール取得

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

トークン埋め込み権限

Authrimはオフライン認可のために、アクセストークンに権限を直接埋め込むことができます。

ロール付き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
  ...

認可チェック

権限チェック

POST /api/authorize
Authorization: Bearer <access_token>
Content-Type: application/json


{
  "resource": "users",
  "action": "delete",
  "subject": {
    "user_id": "user-123"
  }
}

レスポンス：

{
  "allowed": true,
  "reason": "ユーザーは 'admin' ロールを持ち、'users:delete' 権限があります"
}

ポリシー定義

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

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

権限ワイルドカード

  • * - 全権限
  • resource:* - リソースへの全アクション
  • resource:action - リソースへの特定アクション

ベストプラクティス

ロール設計

  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:*"]
    },
    {
      "id": "warehouse",
      "permissions": ["orders:read", "orders:update:status", "inventory:*"]
    },
    {
      "id": "admin",
      "permissions": ["*"]
    }
  ]
}

ABACとの統合

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

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

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

参考資料