概要
Ruby on Railsにおける複雑な認可の設計と実装するための一例を紹介する。
背景
手元で作っているRailsのB2Bサービスの権限に関連する要件が複雑化してきたので、権限モデルをちょっと整理する。
権限が複雑になる原因は、アクターや操作対象といった権限に関するメトリックが多くなること。要件レベルでどれだけメトリックを減らせるかが重要。
ビジネスで利用するサービスの場合、細かい権限設定が要求されるのでメトリックが増えやすい。
今回扱わなければいけないメトリックは以下
- アクター種別
- ロール種別
- ステータス遷移
- Web or APIによる操作
問題
メトリックが3つ以上になった時点で直交表が作成できなくなってしまうため、権限表を作るのが難しくなる。
- メトリックが3つであれば、直交表を複数作ればギリギリ対応できる
- 4つになると表現が厳しい。そもそも理解、暗記、比較も困難。
例えば、Webから操作できる内容とAPIからできる操作を同様にすることによってメトリックを1つ減らせる。
この権限に関する問題は、システム上で表現は可能だしテストケースも作成して担保できる。しかしながら、人間が理解する時や説明するときに困難。
また、細かい要件定義を繰り返してミクロな議論によって実装要件を決めていくといつの間にか複雑に陥っているケースが多い。技術的負債とはまさにこのことである。
理想
あるべき論は以下のスライドに書いてあるとおりと考える。
しかしながら既存のワークフローをDXしてリプレースをかける場合はすでに複雑な要件が決まっていたりするので要件を単純化する余地が少なかったりもする。
どの程度の複雑性になったら複雑と呼べるのか、複雑さを表現するための評価軸を持っておく必要がある。
アプローチ
クリーンアーキテクチャのレイヤと比較して、このような感じで考える。これ以上メトリックが増える場合は、独自にビジネスロジックのレイヤーを追加するなりして対応する必要がある。
背景にあるメトリックを管理するために、Railsにて利用したミドルウェアとスタックを図にまとめた。
- AASMによるステータス遷移
- ロールごとにpunditで管理
- API用、アクターごとに設定を用意する
このように図に整理するとどうやって権限を整理するときれいにできるかが見えてくる。
punditの設定ファイルごとにまとめることによって権限はきれいに表現できそうということがわかる。
まとめ
Railsのシステムにおいて認可をまとめるには以下のようにまとめるのが良さそう。
- AASMではビジネスロジックのステータス遷移についてまとめる
- アクターやアクセスする手段ごとにpunditを用意してpunditの設定ファイルごとに権限表を作成
Discussion