1.7.21

認可モデル

はじめに

本ページではPersoniumを使うにあたって重要となる認可モデルについて記述します。Personiumの認可モデルを最初に理解するためには以下の3つの概念を知ることが鍵となります。

  1. Cell中心の認可
  2. RBAC (Role Based Access Control)
  3. アプリ認可

順に説明していきます。

Cell中心の認可

データアクセスの想定

Cell中心の認可を説明するにあたって、パーソナルデータにアクセスする場面を想定します。次の図はPDS以前とPDSでのデータアクセスする場面を比較して表しています。

before-after

PDSでデータアクセスを行う場合、次のロールが登場します。

ロール名説明
データ主体データの持ち主。上記の図ではAlice, Bob, Carolを指す。
データアクセサーデータアクセスを行う者。データ主体だけでなく、データ主体以外がアクセスする場合も含む。
アプリデータアクセサーが使用して、自身の代わりにデータアクセスを行うアプリケーション。
認可サーバデータアクセスの認可を行うサーバ。
PDSデータ主体単位にデータを格納したサーバ。

上図の通り、データアクセサーは通常アプリを通じてPDSにデータアクセスを行い、PDS内の認可サーバによってアクセス制御されます。

Personiumはこれまでの図左のようなサービス中心の認可モデルではなく、図右のようなデータ主体(主に個人)を中心とした認可モデルを採用しています。

そのため、PersoniumではCellという単位でデータ主体を表し、それぞれのCellが独立したURLを持ち、かつ認可機構を保持しています。具体的には各Cellでは認可のフレームワークであるOAuth2の2つのエンドポイント(AuthzとToken)をCellごとに保持しています。次の表はデータ主体ごとの具体的なURLの例を表しています。

データ主体Cell URLOAuth2 認可エンドポイントOAuth2 トークンエンドポイント
Alicehttps://alice.example/https://alice.example/__authzhttps://alice.example/__token
Bobhttps://bob.example/https://bob.example/__authzhttps://bob.example/__token
Carolhttps://carol.example/https://carol.example/__authzhttps://carol.example/__token

データのアクセスを行うときはこれらのエンドポイントを使って認可が行われた上、適切なデータアクセサーのみアクセスできるように制御されます。

自身Cellへのデータアクセス

データアクセスを考えるのにあたって、まずはアプリを通さずにシンプルにCellに直接アクセスする場合を考えます。

データ主体であるAliceがCell内の自身のデータにアクセスする場合、以下の順序で行います。

  1. Alice Cellのトークンエンドポイントに対して認証、アクセストークンを取得
  2. Alice Cell内のデータに対してアクセストークンと共にアクセス

Access owner's data

トークンエンドポイントで認証を行うときは事前に作成したデータ主体自身を表すAccount(例えばme)とパスワードを使って行います。 [1] また、このとき事前に設定したAccountとリンクされたRoleによってデータにアクセスされます。

Roleはデータアクセス制御に使われるもので、RBACの項で詳細が説明されます。

この方法で取得したアクセストークンのアクセス範囲はAlice自身のCell内となります。

他者Cellへのデータアクセス

次にAliceがBobのデータをアクセスするような他者Cellへのデータアクセスを考えます。このアクセス方法では事前に以下を行います。

  • Bob CellのExtCellにAlice Cellを追加し、Bobから見たAliceのRoleをリンクする

データアクセスするときは以下の順で行います。

  1. Alice Cellのトークンエンドポイントに対して発行ターゲットのパラメータ(p_target)をBob Cellに設定して認証、トランスセルトークンを取得
  2. Bob Cell内のデータに対してトランスセルトークンと共にアクセス

Access other owner's data

PersoniumではCell間の信頼関係によってデータアクセスの制御を行います。事前にデータアクセスされるBob側のCellでExtCellにAlice Cellを設定し、RoleをリンクすることでそのRoleでデータアクセスされます。上記の図ではExtCellのAlice CellとFriendというRoleをリンクしているのでFriendとしてアクセスされます。

この方法で取得したトランスセルトークンのアクセス範囲はBobのCell内となります。

トークン交換による他者Cellへのデータアクセス

他者Cellへのデータアクセスはトークン交換によるもう1つの方法があります。

前述のトランスセルトークンはSAML2 Assertionに従った検証を行うため、トークン長が長くなります。そのため、クライアント-サーバ間の通信や、サーバサイドでの検証処理によってパフォーマンスが悪くなる傾向があります。トークン交換を行うことでパフォーマンス向上を見込むことができます。

トークン交換はトランスセルトークン取得の手順に1手順を追加したもので、それ以外は同じものとなります。

トークン交換では事前に以下を行います。

  • Bob CellのExtCellにAlice Cellを追加し、Bobから見たAliceのRoleをリンクする

トークン交換は以下の順で行います。

  1. Alice Cellのトークンエンドポイントに対して発行ターゲットのパラメータ(p_target)をBob Cellに設定して認証、トランスセルトークンを取得
  2. Bob Cell内のトークンエンドポイントに対してトランスセルトークンと共に認証、Bob Cell内のアクセストークンを取得
  3. Bob Cell内のデータに対してアクセストークンと共にアクセス

Access other owner's data by token exchange

アクセスするRoleやアクセス範囲はトランスセルトークンと同じです。

トークンの更新

アクセストークンやトランスセルトークンを取得する際、アクセストークンの有効期限を更新するためのリフレッシュトークンが発行されます。

リフレッシュトークンを使ってアクセストークンを更新するときは以下の順で行います。

  1. Alice Cellのトークンエンドポイントに対して認証、アクセストークンとリフレッシュトークンを取得
  2. Alice Cell内のトークンエンドポイントに対してgrant_type=refresh_tokenのパラメータとリフレッシュトークンを送信

Refresh Access token

管理用トークン

これまでデータ主体のCellとCell内アカウントがあることを前提としてデータアクセス方法を述べましたが、Personiumのユニットを構築直後はCellが1つも存在せず、それを作る必要があります。また、ユニットを運用する上ではCellをデータ主体でない運用者が操作を行う必要もでてきます。

これらを行うための管理用トークンとしてユニットマスタートークンとUnitユーザトークンが用意されています。

詳細はUnitユーザを参照してください。

トークン種類

これまでデータアクセスを行うために数々のトークンが登場しました。まとめると以下の表の通りとなります。

トークン種類説明有効期限
セルローカルトークントークンを発行したCellで有効なアクセストークン1時間
トランスセルトークン発行されたCellによって指定されたターゲットCellで有効なアクセストークン1時間
リフレッシュトークン既に発行されたトークンをリフレッシュするために使用されるトークン24時間
ユニットマスタートークンユニット構築直後のCell作成などの初期設定、開発やテスト時に使う管理用トークン-
UnitユーザトークンCell作成などの運用に使う管理用トークン-

RBAC (Role Based Access Control)

前項では認証したCell内のAccountやCell同士の関係によってRoleが決定されることを述べました。PersoniumはこのRoleによってデータアクセスをどこまで許可するかを制御するRBAC (Role Based Access Control)の仕組みを備えています。

ユーザーはリソースごとにどのRoleがどの操作まで行えるか(ACL)を設定することでアクセス制御を行います。

ACL

詳細はアクセス制御モデルの項を参照してください。

アプリ認可

これまで単純化のためにアプリを通さないデータアクセス方法について記述しました。しかし、実際にデータアクセサーがデータにアクセスする場合、直接Cellにアクセスすることは基本的になく、アプリにデータアクセスを移譲して行います。

また、PDS上のデータが活用されていくためには以下のアプリが豊富にあることが必要になります。

  • データを提供するアプリ
  • データを利用するアプリ

そのためには、1事業者だけでなく他の事業者がアプリを開発・提供できるようなオープンAPIの活用が必要になります。本項ではこのような想定の元でのアプリの認可の概略について記述します。

PDSにおけるOAuth

様々な提供形態を取るアプリに安全にデータアクセスを行わせるためには適切な権限移譲を行う必要があります。 Personiumではアプリの認可・権限移譲のフレームワークであるOAuthを採用してこれらを実現しています。

先に記述した通り、PDSであるPersoniumは各データ主体のCellで認可サーバの機能を備えております。この場合のOAuthの登場人物に当てはめると以下の図の通りとなります。

OAuth in PDS

具体的な認可のフローはgrant_typeによって異なり、Personiumでは以下のgrant_typeに対応しております。

  • ROPC (Resource Owner Password Credential)
  • 認可コード
  • インプリシット

grant_typeはアプリの形態(信用できるアプリかどうか、サーバーサイドWebアプリかネイティブアプリかなど)によって選択します。選択の基準として以下を推奨します。

grant_type選択基準
ROPCPDS事業者とアプリ提供者が同じである場合など、アプリおよびアプリ提供者の信頼性が高い場合に採用。
認可コードPDS事業者とアプリ提供者が異なる場合などで採用。ネイティブアプリの場合、今後機能追加予定のPKCE併用を推奨。
インプリシット基本非推奨。

次に主に使用するROPCと認可コードフローを説明します。

ROPC (Resource Owner Password Credential) フロー

ROPC Flow

本フローはアプリ上でusername/passwordを入力してアクセストークンを取得するというシンプルなフローです。

PDS事業者とアプリ提供者が同じである場合など、アプリの信頼性が高い場合に使用できるフローです。そうでない場合は次の認可コードフローを採用します。

認可コードフロー

認可コードフローでは、PDS上の画面でデータアクセス同意・username/passwordを入力した後、短命な認可コードをアプリ側で一旦受け取り、アプリからPDSに認可コードを送ってアクセストークンを取得するフローです。

Authorization Code Flow

アプリ認証の項で詳細を記述しています。

Boxの保護

準備中

  1. Personium外部の認証サービスも利用可能です。将来的にはパスワード以外の認証方法にも対応を予定しています。 ↩

← アプリ開発者向けガイドPersoniumにおけるロール →