
# はじめに
業務で新規アプリケーションの認可の設計・実装を行った。こういったものは新規開発じゃないとなかなか触れない部分で、忘れっちゃいそうなので、その際に勉強した認可・権限管理の基礎概念をまとめておく。

# 認可の概念
## 認可とはなにか

認可とは、「ユーザが何をできるか」をコントロールするプロセス。似ている概念として`認証`があるが、これは「ユーザが誰であるか」を確認するプロセスである。

## 認可の三大要素

認可のプロセスでは、「認可三大要素」をもとに認可の判断を下すことになる。「認可三大要素」は以下の3つである。
1. Subject(「誰が」リクエストしているか)
2. Object(「何に」しようとしているか)
3. Action(「何を」しようとしているか)

例えば、GitHubのようなソースコードの管理アプリケーションを想定すると、認可三大要素は以下のようになる。
- 誰が
  - ユーザ1が
- 何に
  - アプリケーションAのソースコードを
- 何を
  - 閲覧する

## 認可モデル

認可には、制御のメカニズムを表現するモデルが何種類か存在する。

1. RBAC
2. ReBAC
3. ABAC

<img src="https://assets-global.website-files.com/5f1483105c9a72fd0a3b662a/6093f4823b3749ec0a50afa5_TDy-IH54xrFUhzCHY-hpAvqFRTldduafw3uzMJJbq6oxrjkGagg-yU641eR053As3cSgiirDX-_PvVX8itjMV5C-OPVRHtVky8HW34FkEYaS1XqQCr13-sCpsjgrpE9KKCZOguZG.png" alt="drawing" width="300"/>

引用: https://www.osohq.com/academy/relationship-based-access-control-rebac

### RBAC
RBAC(アールバックと発音するらしい)は、人やグループに「ロール」を割り当て、そのロールに基づいて権限を制御するモデルである。例えば、「Admin」ロールを持つユーザのみ、重要なAPIにアクセスできる、などである。

### ReBAC
ReBACは、リソース間の「関係」に基づいて権限を制御するモデルである。例えば、フォルダへのアクセス権限を持つユーザは、フォルダ内のファイルへのアクセス権限を持つ、といったような制御ができる。RBACよりも柔軟な制御が可能になる。

### ABAC
ABACは、リソースの「属性」に基づいて権限を制御するモデルである。このモデルでは、実質的に無限の認可ロジックを適用することができる。例えば、isPublicがTrueのリソースには誰でもアクセスできる、業務時間外は機密ファイルにアクセスできない、といったような制御が可能になる。ReBACはABACの一種だと言うことができる。

# 認可のアプリケーションへの組み込み方

認可は、ユーザからすると正しく実装されて「当たり前」でありながら、バグがあると致命的な問題になりえる領域である。しかも、アプリケーションへの組み込み方をミスると簡単にバグや実装漏れが起きてしまう。にも関わらず、認可をどのようにアプリケーションに組み込むか、といった知見は(自分の印象では)あまり共有されていないように感じる。

## 何も考えずに組み込むとどうなるか

認可について意識しないままアプリケーションを実装していくと、以下のようにアプリケーションロジックと認可のロジックが混ざってしまいがちだと思う。
```go
if user.isAdmin {
    // アドミン向けの処理
} else {
    // その他のユーザ向けの処理
}

// 上記のようなロジックがソースコードの色んな場所に分散して存在する
```

上記のように、認可とアプリケーションロジックが分離できていないと、実装ミスが発生しやすく、変更容易性も低くなります。

## EnforceとDecision

ではどのようにアプリケーションに組み込むかというと、認可のロジックを一箇所に集約して、それを各所で呼び出すようにする。認可の用語では、認可の判定を下すことを`Decision`、その結果を適用することを`Enforecement`と呼ぶ。以下の画像のように、`Decision`は一箇所で集中管理してテストを厚く書き、アプリケーションの必要な箇所で`Enforcement`を行う。重要なのは、認可のロジックが一箇所にまとまっていることで、認可の適用はどこでやろうが何回やろうがかまわない。

<img src="https://assets-global.website-files.com/5f1483105c9a72fd0a3b662a/60516eaf35e59b6c28d3f34c_WFrzEd5ZWHDKF7jFh7Px7-0sPYCEMmosPJRKCeuy4QSjg9EoIfKGThEg-0OkBVFUZBELsirpT61LL1a57VyheldVOBH9BGBJ2c4cxJhcY2Hw6B4xkDjo34SQOLS9Nsz7QjYms6ZJ.png" alt="drawing" width="600"/>

引用: https://www.osohq.com/academy/what-is-authorization#addingauthzapp

### 認可を適用する箇所
認可を適用(`Enforcement`)する箇所にもパターンがある。
1. リクエストの入り口箇所
2. コントローラー層
3. DBへのアクセス箇所

個人的には、リクエストの入り口箇所で適用するのが良いと考えている(し、そういうアプリケーションが多いのではないだろうか？)。理由は、この層で認可の判定ができていれば、それ以降のアプリケーションコードでは権限について考えなくてすむためである。

また、APIのパス・メソッドは初期に定義してから頻繁に変更することは少ないため、安定して使うことができる。[Webアプリケーションフレームワークのミドルウェア](https://echo.labstack.com/docs/middleware/casbin-auth)で適用すれば、権限の適用漏れも防げる。

<img src="https://assets-global.website-files.com/5f1483105c9a72fd0a3b662a/6051515dfca17b4dac8d2162_eFvLwOry4DOBdqhLIyjwrPA1B3B9PMtu3m6b0iiBldsLUU-fsr8_xNcHOVqFQDkbvor_gQxlDPZ1x-F2L_-ypm2jFIfZuYMeK3PeTF9rJS96hU_FHZlQSC2TfJmnTGaJ5ON8i99b.png" alt="drawing" width="600"/>

引用: https://www.osohq.com/academy/what-is-authorization#addingauthzapp

## アーキテクチャパターン
ほとんどのアプリケーションでは、認可のロジックはアプリケーション内に実装することが望ましい。一方、巨大なサービスやマイクロサービスアーキテクチャを採用している場合は、認可専用のマイクロサービスを追加して認可のロジックを集中管理する。このアーキテクチャを採用しているのが、[GoogleのZanzibar](https://www.osohq.com/learn/google-zanzibar)である。

自分が開発したことがあるのは前者のみなので、ここらへんの詳細は[こちら](https://www.osohq.com/academy/what-is-authorization#addingauthzapp)を参照してください。

# 参考
- [Oso Authorization Academy](https://www.osohq.com/academy)
- [認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）](https://zenn.dev/she_techblog/articles/6eff1f28d107be?redirected=1)
- [アプリケーションにおける権限設計の課題](https://kenfdev.hateblo.jp/entry/2020/01/13/115032)
- [属性ベースのアクセス制御（ABAC）とは？ メリットと適切なアクセス制御モデル](https://www.okta.com/jp/blog/2020/09/attribute-based-access-control-abac/)


認可・権限管理の基礎概念

認可ライブラリCasbinでABACを実装してみる。


# はじめに
認可専用のライブラリである[Casbin](https://casbin.org/)を使って、[ABAC](https://en.wikipedia.org/wiki/Attribute-based_access_control)を実装してみる。Casbinでは、単純にルールを羅列するのではなく、[eval()という組み込み関数](https://casbin.org/ja/docs/abac#scaling-the-model-for-complex-and-large-numbers-of-abac-rules)を使用することで、任意の認可ロジックを簡潔に組み込むことができる。なお、CasbinそのものやRBAC/ABAC等の認可の概念に関する説明は本記事ではしない。

eval()では、[公式ドキュメントの例](https://casbin.org/ja/docs/abac/#scaling-the-model-for-complex-and-large-numbers-of-abac-rules)のように直接ロジックを渡すこともできるし、[`AddFunction`というAPI](https://casbin.org/ja/docs/management-api#addfunction)を使ってGoで記述した任意の関数を登録し、それをポリシー内で呼び出すこともできる。今回は後者の方法を使い、DBへのアクセスが必要な権限管理のロジック、という想定で実装してみる。

# 実装するシナリオ
今回は、病院で使用するシステムを想定し、「自分が担当している患者のデータにのみアクセスできる」という要件を実装する。

# 実装
## モデルの定義
`model.conf`ファイルにモデルを定義する。

```shell
[request_definition]
r = user, obj, method

[policy_definition]
p = path, method, rule

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = keyMatch5(r.obj.Path, p.path) && (r.method == p.method || p.method == "*") && eval(p.rule)
```

## ポリシー
`policy.csv`にポリシーを記述する。

```csv
p, /patient/{patient_id}/record, *, "is_assigned_patient(r.user.ID, r.obj.ID)"
```

## APIと認可用ミドルウェア
```go
package main

import (
	"fmt"
	"net/http"
	"strconv"

	"github.com/casbin/casbin/v2"
	"github.com/labstack/echo/v4"
)

var enforcer *casbin.Enforcer

func main() {
	e := echo.New()

	var err error
	enforcer, err = casbin.NewEnforcer("model.conf", "policy.csv")
	if err != nil {
		panic(err)
	}

	enforcer.EnableLog(true)

	// 任意の関数をCasbinに登録する
	enforcer.AddFunction("is_assigned_patient", func(args ...interface{}) (interface{}, error) {
		// NOTE: Casbinは文字列型のみ対応している https://github.com/casbin/casbin/issues/113
		doctorIDStr, ok := args[0].(string)
		if !ok {
			return false, fmt.Errorf("failed to get doctorID from casbin policy")
		}

		patientIDStr, ok := args[1].(string)
		if !ok {
			return false, fmt.Errorf("failed to get patientID from casbin policy")
		}

		doctorID, err := strconv.ParseUint(doctorIDStr, 10, 64)
		if err != nil {
			return false, fmt.Errorf("failed to parse doctorID: %w", err)
		}

		patientID, err := strconv.ParseUint(patientIDStr, 10, 64)
		if err != nil {
			return false, fmt.Errorf("failed to parse patientID: %w", err)
		}

        // DBから、リクエストを送った医者が担当している患者かどうかを取得する(今回はモック)
		return isPatientAssignedToDoctor(int(doctorID), int(patientID)), nil
	})

	e.Use(authorize)
	e.GET("/patient/:patient_id/record", func(c echo.Context) error {
		return c.String(http.StatusOK, "Access Allowed\n\n")
	})
	e.Logger.Fatal(e.Start(":1323"))
}

type User struct {
	ID int
}

type Object struct {
	ID   int
	Path string
}

// 認可をミドルウェアで実施する
func authorize(next echo.HandlerFunc) echo.HandlerFunc {
	return func(c echo.Context) error {
		path := c.Request().URL.Path
		method := c.Request().Method

		userIDStr := c.QueryParam("user_id")
		userID, err := strconv.Atoi(userIDStr)
		if err != nil {
			return echo.NewHTTPError(http.StatusBadRequest, err.Error())
		}

		objectIDStr := c.Param("patient_id")
		objectID, err := strconv.Atoi(objectIDStr)
		if err != nil {
			return echo.NewHTTPError(http.StatusBadRequest, err.Error())
		}

		obj := Object{ID: objectID, Path: path}

		ok, err := enforcer.Enforce(User{ID: userID}, obj, method)
		if err != nil {
			return echo.NewHTTPError(http.StatusInternalServerError, err.Error())
		}
		if ok {
			return next(c)
		}
		return c.String(http.StatusForbidden, "Access denied\n\n")
	}
}

func isPatientAssignedToDoctor(doctorID int, patientID int) bool {
	if doctorID == 1 && patientID == 1 {
		return true
	}
	return false
}
```

注意点として、[CasbinのポリシーはString型にしか対応していない](https://github.com/casbin/casbin/issues/113)。文字列型以外を渡すと正しく判定できないことがあるので注意が必要。

# 動作確認
```shell
// 自分が担当している患者の情報は取得できる
$ curl 'http://localhost:1323/patient/1/record?user_id=1'
Access Allowed

// 自分が担当していない患者の情報は取得できない
$ curl 'http://localhost:1323/patient/2/record?user_id=1'
Access denied
```

# 参考文献
- https://casbin.org/ja/docs/abac
- https://future-architect.github.io/articles/20221004a/

masatora.net