Source

jk / docs / source / flows.rst

OAuth/Connect 情報連携基盤フロー

扶養家族情報取得に関するサンプルUse Cases

  • 個人の扶養家族情報を役所から取得するに当たり、個人別に要求するかまとめて要求するかを考慮しています。
  • 数万人分の処理を一度に行う事が想定されるので性能面の考慮も必要です。

UC3: 申告者に対する扶養家族情報を取得する

  • request_file : identities = [田中@港区,鈴木@目黒区,斉藤@渋谷区 ]
  • UC1を3回やるか、UC2を3回やるかのどちらかでも対応が可能
  • :ref:`flows_sequence_uc3`

Connect/OAuth プロトコルでの考慮点

Client Credentials Flow

分散クレーム(Distributed Claim)

  • UserInfo Endpoint は ConnectのDistributed Claimで実際の個人情報(扶養家族)の場所(区役所)とそのアクセストークンを返します。
  • Clientが事前に貰うアサーションには、UserInfoにアクセスできる許諾とともに分散クレーム先にアクセスできる許諾が記載されている必要があるだろう。

その他のエンドポイントでの機能

スペック以外の考慮点

OP != Resource Serverでのaccess_tokenの検証

  • OAuth/Connect では定義されていないので、何らかの手順を構築する/標準化することが必要です。

Server-Client間の識別子

通常のOAuthではリソースアクセス対象となるオーナー個人の識別子は一つなので、問題とされる事はないが、 複数の個人データを一度に返す場合は、識別子の扱いを考える必要がある。

Serverが中間の識別子を生成
  • Client と Serverとの間で個人(田中さん)の識別子をどうやって共有するか?が問題です。
  • 1つの考え方は ClientとServerの間で、アドホックな識別子を取り決めてそれに対して双方マッピングするというやり方です。
  • ここでは、Serverがアドホック識別子を発行して、それに紐づいたServer_PPIDの対応表をOPだけが分かる形で暗号化するというやり方を想定しています。
ID項目 ID例
田中さん マイナンバー 00011122245
田中さん OP local id d70ffeb84ddb11e19bf7080027dd6a89
田中さん Server PPID 86fe7fdb8ac8f282250f44c7b53e5f1830ebabebbc7986992634582279b484a2
田中さん Client PPID 708a06012041da338eea54c82c584e6e
田中さん in Resource returned by Server 1
田中さん in EncMap returned by Server Encryption('server_op_pairwise_key', [{'1': '86fe7fdb8ac8f282250f44c7b53e5f1830ebabebbc7986992634582279b484a2'}] )
田中さん in DecMap returned by OP [{'1': '708a06012041da338eea54c82c584e6e'}]
OP: Server が受け取ったAccess Token の検証 (TokenRes)
  • アクセストークンを検証します。

  • トークンに対してどのPPIDのデータを処理すべきであるかを返答(TokenResDoc)します。

  • Endpoint はどうやってリゾルブするか?

    • Discovery
    • アクセストークンに入れる
Server : 一時ID = Server_PPIDの暗号化対応表(EncMap)
  • Resource Endpointの返答に、 一時ID = Server_PPID、の暗号化対応表(EncMapTable)を返します。

  • OPだけが復号化可能です。

    • OPにServerをRegistrationする時に設定した共有キーを使う
    • OPのパブリックキーを使って非対称暗号化する
  • Clientは応答のデータ部分はわかりますが、その一時IDは誰のIDであるかはわかりません。

OP : 一時ID = Client PPIDの対応表を返答する(DecMap)
  • Clientが受け取ったEncMapTableをOPが復号します。

  • OPは復号後にServer_PPIDをClient_PPIDに変換します。

  • このテーブルをClientに返答します。 ( DecMapTable)

  • Endpointはどうやってリゾルブするのか?

    • Discovery
    • アクセストークンに入れる
    • UserInfo に入れる
OPが中間の識別子を生成する方法

これとは別にClientからのリクエストに基づいてアクセストークんを作る際に、 OPが中間の識別子を作って、Client とServerにそれぞれのPPIDと対応する表を渡す と言う方式も考えられる。

その他の考慮点

User Info を受け取るまでのスケーラビリティ

  • グループ識別子で一括要求ができれば極端に性能要件を下げる事ができます。
  • 一括でデータが抜かれることに対するリスクとのトレードオフです。

リソースリクエストのスケーラビリティ

トークン解決(TokenRes)

  • OPはトークン自体の検証をする必要があります
  • OPはServerから要求を受け取った1つのトークンに対して関係するPPIDを生成して返答する必要があります

EncMapの作成

  • ServerはOPから受け取ったPPIDに対するユーザーに対して一時ID振って対応表を作る必要があります
  • PPIDがグループ識別子だとしたら、そのグループに含まれるServerでの全てPPIDに対して対応表に入れる必要があります。
  • 対応表を暗号化します。 一般に非対称暗号の方が性能要件があがります。
  • 対応表のサイズに対しては共有キー暗号と非対称暗号ではあまりかわらないでしょう(非対称暗号では共有キーをパブリックキーで暗号化するので)。

グループか個人ごとか?

  • グループのリソース要求だとトークン解決と暗号化が1回ですみますが、個人毎だと人数分の回数がかかります。

DecMapの返答

  • OPはClientの要求に対して、EncMapの復号化をおこないます。
  • 復号されたPPIDはServer PPIDなので、Client PPID に変換します。

認可機関のログ記録

OPはWebサーバーログ以外に、アプリケーション的に少なくとも以下の4つのログを記録します。

  • UserInfoへのトークンを発行した
  • UserInfo がDistributed Claim のトークンを発行した
  • ServerからのTokenRes要求
  • ClientかのDecMap要求

JSONのサイズ

  • 大量のユーザ−の情報を要求する時に、1 JSON当たりに余りに多くのユーザ−の情報を入れると問題があるのでは?

    • 実際の個人情報も、EncMapも同じ問題が有り得る
    • JSONのストリーミング処理についてはよくわかりません
    • 複数のJSONをマルチパートでレスポンスできるのか?