権限システム

CURCUS の権限・セキュリティ関係についてのまとめ。

3つの権限タイプ

ログイン済みユーザには、以下の3つの権限モデルによるセキュリティチェックがかかる。

特定のプロジェクトに結びつかない幾つかのグローバルなロールは、グループに直接付与される。このようなグローバル権限には以下のようなものがある。

各プロジェクトは、そのプロジェクトにアクセスが出来るグループを役割毎に指定できる。

プロジェクトに関わるあらゆる API 操作において、ユーザが該当プロジェクトの該当操作に関する権限を持っているかどうかを確認すること。

各シリーズ（DICOMシリーズ）にはドメインが付与されている。シリーズに関わるあらゆる API 操作において、ユーザが該当シリーズのドメインへのアクセス権限を持っているかどうかを確認すること。

上記の3つの権限タイプはそれぞれ独立しており、1つの操作に対して複数の権限によるチェックが必要なことある。例えば特定のケースに対して読み込みを行う API を利用するユーザは、以下の両方の権限を持っている必要がある。

CIRCUS DB における個人情報とは Series.personalInfo に集中して記載されている、患者 ID、氏名、性別などの情報のこと。Series Instance UID は個人情報としては扱わない。

個人情報を利用できるかどうかは以下のルールに基づいて決める。

プロジェクトレベルの権限として特定のプロジェクトへの showPersonalInfo 権限が付与されている場合、そのプロジェクトに紐付いているシリーズの個人情報を利用することができる。
- ケース検索の API で個人情報を利用した検索ができる。個人情報を利用可能なプロジェクト ID の一覧を機械的に算出できるため、それを用いてクエリを行う。
showPersonalInfo グローバル権限がある場合、プロジェクトに結びついていない状態で、ドメインレベルでアクセス可能なシリーズの個人情報を利用することができる。
- シリーズ検索・シリーズ取得の API で個人情報を利用できる

プレファレンスで個人情報を表示しないことにした場合は API でも個人情報を受け取らないようにしたい。API で不要なフィールドを省略するためのジェネリックな方法を検討し、ここで適用する。

バグの温床になるため、権限関係のコードを各 API 機能を実装する部分に分散して書いてはならない。

各機能を実装するミドルウェアはその機能を実現することのみに集中し、権限を処理するミドルウェアは別に用意し、ルーティングのレベルで判断させること。アプリケーションのブート時に、以下のようなミドルウェアのスタックが構築されるようにする。