1.7.21

アプリ認証

アプリ認証が必要な背景

PersoniumのCellは様々なアプリケーションプログラム（アプリ）とデータをやり取りすることを前提としたデータストアオブジェクトです。アプリやアプリベンダを限ることなく誰でもどんなアプリでも作ることができるオープンなアーキテクチャをとっているため、金融、健康、ゲームといった様々な分野にわたり、PC、スマートフォン、ウェアラブルデバイス、サーバなど様々な機器の様々なプラットフォーム上で動作する様々なアプリを様々なアプリベンダが開発できます。

一方でオープンなアプローチをとる以上は悪意のアプリ作者による悪意のアプリがこの中に混入することは避けられません。つまり例えばフィッシングアプリなど悪意を持ったアプリを、そうとは知らずにCellの所有者が使ってしまうケースは必ず発生します。その際、正当なアプリのデータが流出したり改ざんされてしまうようなことがあってはなりません。

Box とアプリ認証

そこでPersonium のCellは、そのような不正なアプリから正当なアプリのデータを守るための機構を用意しています。それがBoxとアプリ認証です。BoxはCell内部につくられる独立性を持ったデータ領域で、単一のアプリまたは単一のアプリベンダによって提供されるアプリ群のために占有的に使われることが意図されています。多くの場合アプリ毎のデータ領域といってしまって差し支えないでしょう。

これと対をなすのがアプリ認証で、文字通りアプリを認証するための機構です。すなわちCellが受け付けたリクエストがアプリAからのものなのか、アプリBのものなのかを判定し、アプリA用のBoxへのアクセスをアプリAからのリクエストのみに限るようなことを実現するために必要になるものです。

Cellはどのようなアプリをどのようなユーザが操作しているかを確認してアクセス制御を行います。そのため多くの場合アプリ認証はユーザを認証するためのユーザ認証と組み合わせて使用します。

認証の種類目的
ユーザ認証リクエスト主体のユーザを識別するとともに、なりすましではなくリクエストが正当なユーザによるものであることを確認するための認証プロセス
アプリ認証リクエスト主体のアプリを識別するとともに、なりすましではなくリクエストが正当なアプリによるものであることを確認するための認証プロセス

アプリ認証の仕組み

Personiumのアプリ認証はOAuth2.0 におけるクライアント認証の枠組みを応用しています。つまり、CellはアプリからOAuth2.0のトークンエンドポイントに対して（ユーザ認証のための情報とともに）以下を受け取ったとき、（正当なユーザが）正当なアプリを使っていることを証明するアクセストークンをBearer Tokenとして発行します。

  • client_id : アプリ識別情報
  • client_secret: 正当なアプリにしか発行しえない情報

Personiumでは具体的には以下の情報を使う仕様としてます。

OAuth 2.0 パラメタPersoniumでの指定値概要
client_idスキーマURLアプリやアプリ群・アプリ開発元を示すURL
client_secretアプリ認証トークン上記URLをIssuer・Subjectとする有効な署名のついたSAML Assertionをbase64urlエンコードした文字列

アプリ認証をするための設定

概要

  • アプリケーションがBox内のデータにアクセスするためには、通常、まずサービス提供者が管理する中央Cell（アプリCell）にてアプリクライアントとしてのTarget指定で認証を行い、
    その後通常のID/PWおよびClientID・ClientSecretの指定によるSchema認証を実施することで、そのBoxのみにアクセスするトークンを発行します。

  • または、通常のID/PW認証を実施したときに取得したRefreshTokenを用いて有効期限更新をする際に、
    上記と同様にClientID・ClientSecret指定によるTransCellトークン発行が可能です。（v1.5.2以降）

前提

  • Schema認証を実施するには、以下のCellが必須となります。
    • ・{appcell}: アプリCell（スキーマ認証Cell）
    • ・{cell}: データ主体Cell

認証の流れ

  • PersoniumではアプリCellのアカウントに特殊ロール（{issuerUrl} + /__role/__/confidentialClient）を結びつけることで、
    スキーマ認証（アプリ認証）を行います。（スキーマ認証レベル confidential の場合）
  • データ主体Cell認証時のclient_idと client_secret にスキーマ認証情報を入れてユーザ認証を行うことでユーザ認証、スキーマ認証の評価を一緒に行います。

Schema認証手順

アプリCellへアプリ認証情報設定

  • アプリCellにアカウント作成（通常のアカウント作成）
  • アプリCellにロール作成（通常のロール作成）
    • ロールの作成は任意。最上位のスキーマ認証（Confidential Client）を行う場合のみ実施
  • アカウントとロールの結びつけ（通常の結びつけ処理）
    • ロールの作成と同じ理由により任意

データ主体Cellのコレクションにスキーマ認証レベル設定

  • ACLを使ってスキーマ認証レベルの設定を行います。

  • スキーマ認証設定ACLのサンプル

<D:acl xmlns:D="DAV:" xml:base="https://demo.personium.io/cell/__role/box/"
xmlns:p="urn:x-personium:xmlns"
p:requireSchemaAuthz="{スキーマ認証レベル}">
    <D:ace>
        <D:principal>
            <D:all/>
        </D:principal>
        <D:grant>
            <D:privilege><D:read/></D:privilege>
            <D:privilege><D:write/></D:privilege>
        </D:grant>
    </D:ace>
</D:acl>

スキーマ認証レベルの取りうる値

レベル値内容
noneスキーマ無しでアクセス可能（デフォルト）
publicスキーマがあればアクセス可能
confidentialスキーマに特殊ロールconfidentialClientがあればアクセス可能

アプリCellでの認証

  • アプリからアプリCellに対して認証してデータCell向けトランスセルトークン取得
  • ここでは通常のパスワード認証

データ主体Cellでの認証

  • Personiumアプリからデータ主体Cellに対して通常のパスワード認証をすると同時にアプリCellから受け取ったトランスセルトークンをclient_secret、
    アプリCellのURLをclient_idに入れて認証します。
  • client_secret 内のissuerとclient_idをチェックし、一致していれば発行するアクセストークンにスキーマ情報（URL）を付与します。
  • client_secret 内のロール（AttributeStatement\Attribute\AttributeValueの値）をチェックし、
    ロールが特殊な値（{issuerUrl} + /__role/__/confidentialClient）であればスキーマ情報の後ろに#c（conficentialであることの印）を付与します。
curl -X POST '{UnitURL}/{cell}}/__auth' -d \
'grant_type=password&username=user&password=pass&client_id={UnitURL}/{appcell}/&client_secret={アプリCellから受け取ったトランCellトークン}'

Box及びコレクションのデータアクセス制御

  • Box及びコレクションにアクセスする際のアクセストークンのスキーマ認証情報と、
    Boxに設定されているスキーマ（アクセス先がコレクションの場合属するBox）のチェックを行います。

  • アクセスするBox/コレクションのスキーマ認証レベル設定とアクセストークンのスキーマ情報を比較し、
    レベル設定に合わない場合はアクセスを拒否します。

    • ・none => スキーマ認証チェックを行わない

    • ・public => スキーマ認証チェックを行い、スキーマ認証されていればアクセス可能にする

    • ・confidential => スキーマ認証チェックを行い、特殊ロール（confidentialClient）があればアクセス可能にする

  • アクセスするBoxのスキーマ値とアクセストークンのスキーマ値を比較し、値が異なる場合はアクセスを拒否します。

← アクセス制御モデルSingle Sign On →