#ここまでで Personium に触れる環境ができたので、Personiumを利用しどんな風にアプリケーションを構成するべきなのか整理してみる。
##１． ペルソニアム なのです！
Personium のドキュメントの一番先頭に、以下のような図で説明されています。
まぁ概念的なとところは理解できるんですが… それはどんな構造でどんな風に実現されているか、なかなかわかりづらいですね！？
たぶん＂私＂の位置が重要なのでしょうね。 そして矢印が「一方通行」と「双方向」の違いも大きいのかと想像できます。
そしてここで一番驚いたことが…
#####Personium は ＂ペルソニウム＂ではなく＂ペルソニアム＂なのでした。
もくもく会とかでOSSチームの皆さんとお会いしても、どうしても意識しないと＂ペルソニウム＂と発音してしまうのですが、プロダクトの名称を間違って呼ぶのは大変失礼なこととは認識していても、＂ペルソニアム＂とは発音しづらく…
この年齢になると、音で覚えたことって身体に染み付いていてなかなか修正できなく、いつもすみません。
###ではまず、私が理解している Personium を簡単にお伝えしましょう。
Personium はサーバーサイドでAPIを提供するサービスです。
なのでAPIを利用して「ユーザー認証」「データの保管」「データの参照」機能を利用すれば、アプリケーションは作れます。これはこれで、アプリケーションサーバーのセットアップやDBのインストールを行い、そして（開発言語に対応したフレームワークなどを利用しつつ…）セキュリティを維持した認証やデータアクセスの基盤部分のアプリケーション部分もコーディングすることは可能なのですが、いろいろ気を使って構築する必要がありますので、この部分を Personium のAPIに任せてしまうことによる効果は大いにあります。
しかしOSSチームの理想は、厳密なPDSとしての利用方法を推奨し、且つ Personium を基盤とするエコシステムを前提にしたアプリケーションをイメージしており、まぁやはりせっかく Personium を利用するのであれば、厳密なPDSとしての利用方法を目指すべきですよね。
サンプルやドキュメント上もこちらのアプリを前提に記載されていて、いろいろ把握しておかなければならないお作法などもありますので、早いうちにこの＂厳密なPDSとしての利用＂について理解しておくべきでしょう。
上記を簡単に説明されているドキュメントが以下になります。
「Personium アプリ」と「Personium を使ったアプリ」
っで私の使命は、「情報銀行のプラットフォームとして利用できるかもしれない… 検証用のPDS（Personium） 構築してみる。」だった事を思い出したので、どうしても＂厳密なPDSとしての利用＂方の「Personium アプリ」について把握しなければならず「Personium を使ったアプリ」に逃げ込む事はできません。残念ながら…
しかしこの「Personium アプリ」をどう構造すべきで何がメリットなのかが、当初本当に分からず苦労した経験があります。まずはココを簡単に説明できると Personium に興味を持ち始めたばかりの方々にも素早く理解を深めてもらえるのではないかと考えます。
##２．本当にざっくりと… まとめ ちゃいます
Personium は 前のエントリーで構築したユニット内に、ユーザーCellやアプリCell、データをストアするBoxなどで構成されます。構築した Personium でAPIなどで触って見る限りでは、ユーザーCellとアプリCellの違いを感じることができず大きく戸惑ったのですが、やはりアプリを構想する上でこの部分はしっかりと理解すべきですが… ここをちゃんとわかりやすく説明するドキュメントも見つけられませんでした。
そして私が Personium を理解しづらかったもうひとつの理由が… ユーザーという概念の中にアプリが埋め込まれているのです。しかも複数のアプリです。
一般的なWebアプリケーションは、1つのアプリケーション（システム）の中に、複数のユーザーの＂マスター＂が存在し、1箇所に集められているデータの中の、マスターに登録されたユーザーに関連するデータを抽出し、目的のために利用する構造ですよね。
ここが大きく違うんです… まるで逆！！
#####そして、そんな意表をつく構造なのに、それを実現している構造は以下のように、すこぶる淡白に説明してくれています。
私には、この図からは実際の Personium の構造を想像することすらできませんでした。
ということでまずは… ＂そんなの簡単に想像できるじゃん！＂という内容かもしれませんが、私が把握している内容を整理してみることとします。
###Personium の基本構造の整理
- Personium は サーバー ≒ Unit 上で稼働しパーソナルデータストア（PDS）機能を提供する。
- Unitは唯一の存在ではなく、複数の運営者により分散的にエコシステムの一部を担うことができる。
- 複数のUnitのユーザー間で、アプリ単位でデータの連携を取ることができる。
- ユーザー ≒ Cell という関係にあるユーザーセル（User Cell）を基本の単位となる。
- ストックする情報 ＝ Box という関係にあるBoxをUser Cell内に保持することができる。
- Box内では、WebDavとOdataのインターフェースで情報にアクセスができる。
- Cellには、アプリケーションの実態を持つ、特別な体系のアプリCell（App Cell）も存在する。
- Cellには、Unit管理者権限を有する特別なユーザーとしての、削除不可能なunitadmin Cellも存在する。
- Personiumサーバーは、APIやサーバーサイドスクリプトを介しユーザーのリクエストに対しレスポンスする。
##認証についての特徴
- ログインするためのパスワードはUser Cellの内部に暗号化されて保管されている。
- 認証成功後に発行されるTokenの受け渡す事で、ログイン状態であることを確認しレスポンスを返す。
- エコシステムでは HomeApp を提供し、一般のアプリにはログイン機能を必要としない環境が実現されている。
- TokenやCookieを利用しログイン完了状態である事を確認できるため、アプリ内に認証機能は必須ではない。
####ホームアプリ（ HomeApp ）のイメージ
OSSチームから提供されている HomeApp ではこんな画面からログインします。
##３．「Personium アプリ」と「Personium を使ったアプリ」の比較
＂「Personium アプリ」と「Personium を使ったアプリ」＂
コトバで言うのは簡単なのですが、なかなか正確にこの差異を伝えるのは難しいのです。そしてこれもまた… Personiumのドキュメントの中にはこの違いを明確に伝えるイメージを見つけられません。私はこの差異については、もくもく会に参加しOSSチームのメンバーの方々と直接会話し、根掘り葉掘り質問してようやくイメージが整いました。今回はそのイメージを示し説明したいと思います。
###「Personium アプリ」のイメージと説明：
っが… 実際に伝えたいことを1つのイメージをまとめてみようと思うと、これがまた難しかったぁ…
イメージで表現できていない内容も含め以下に説明します。
####説明：
- ユーザーは UserCell を自身のデータをストアする基本の単位として宣言される。
- ログインに必要なパスワードは UserCell に保持されている。
- アプリのインストールは、＂スキーマ＂という設定値として対応する AppCell のURLが登録されている情報を持った Box をインポートすることで実現する。
- Box は＂スキーマ＂と AppCell のアプリケーションが利用する WebDavやOdataの定義などが記載されている .bar ファイルとして提供される。
- アプリのインストールとは、この .bar ファイルをインポートする事が、WebDavやOdataの定義を実態として作成し、ユーザーがアプリケーションを利用することができる状態にすることである。
- AppCell に収められているアプリケーションは、ユーザーがログイン時に Personium から期間限定で発行されてる Token を Personium に渡すことで認証とし、ユーザーの情報にアクセスする権限を得る。
- Token を発行するためのログインは、HomeApp と呼ばれるアプリケーションの提供者以外の運営者（PersoniumエコシステムではOSSチーム）が提供するアプリケーションで実現する。
- HomeApp が取得した Token はブラウザのローカルストレージやCookieを利用し、アプリケーションに渡す。
- PersoniumエコシステムではOSSチームが提供する HomeApp は、前述の Box のインポートする機能も提供する。
- UserCell には複数のアプリに対応した複数の Box をインストールすることができる。
- UserCell は、同一ユニットに限らず別のユニットのアプリケーションをインストールすることも可能である。（これを実現するには、前のエントリーのユニットの構築には記載していない、他のユニットを信用する設定を加える必要がある）
###「Personium を使ったアプリ」のイメージと説明：
####説明：
- ユーザーは UserCell を自身のデータをストアする基本の単位として宣言される。
- ログインに必要なパスワードは UserCell に保持されている。
- AppCell・HomeApp は不要である。
- Box に＂スキーマ＂は必要なく WebDavやOdataの定義などが定義されてていれば良い。
- ログインは各アプリで実装される必要があり、実装中で取得された Token を Personium に渡すことで認証とし、ユーザーの情報にアクセスする権限を得る。
- Box 内の WebDavやOdata 情報に対し、Token を利用し Personium のAPIを通してアクセスする、DBを利用する通常のアプリケーションのように構築することができる。
Personium エコシステムの特徴のまとめ
- ユーザーの情報をアプリとは独立したCell内のBoxに保持する構造で、アプリ単位にユーザーの情報が分散しない仕組みが実現されている。
- 認証機能はアプリ内で実現する必要がないため、悪意を持ったアプリからのパスワードの漏洩することがない環境を整えられる。
- アプリで利用するデータはBoxにセットされており、Boxに紐づいたアプリ以外からのアクセスの制限が実現されている。
####さて、なんとなくは Personium の利用方法は把握していただけたしょうかねぇ…
このエントリーに取り掛かる前は、もっといろんなことをわかりやすく説明できるような気がしていたのですが… まぁこの程度になってしまいましたね。 失礼いたしました。
サンプルのコードを覗かしてもらったりすると、ここで説明するよりもず〜っとセキュリティに気を使い Personium の特徴を活かしつつ、非常に丁寧に実装されています。
ただしやはり、その考え方と実装方法を、これから Personium を利用しようとする一般の運営者に、正確に伝え正しくアプリケーションを構築してもらうには、ちょっとドキュメントが淡白ですよね…
私にはサンプルアプリのコードを参照するだけで理解を進めるのはもう限界かな… という気がしていますので、これについても今後OSSチームに確認しながら整理したいと思っています。
（一応「ブラウザアプリ起動フロー」という資料は、非公式に見せてもらっているのですが、それもいまいち難しくて… 噛み砕いて説明してもらいながら整理したいですね。）
##４．じゃあ、プロトタイプ・アプリケーションはどんな構造にしようかな？？
私は、実際にいろいろな Personium の機能に触れるために、プロトタイプのアプリケーションを作ろうと考えていました。しかしこのエントリーのここまでに説明したような Personium の特徴的な構造もセキュリティについての拘りもわからず、どんな構造にすべきか戸惑っていました。
そしてそこでどうしてもハードルとして開かるのは、HomeApp の存在でした… だって、自分のアプリ以外のアプリにログインするんですよ！？全く理解できませんでした。
そしてそれ以上に難問であると感じたのが、Persnoium を使うべきであると会社に報告する際に、HomeApp の存在の説明の仕方ですね。ある程度 HomeApp の意義を理解している私が考えても、この HomeApp の存在を受け入れる理由を説明できる気がしませんでした。もしすでにエコシステムが繁栄していて、エコシステム対応のアプリも多数あり、そこにデータをストアしているユーザーが＂数百万人いる＂とかなら説明を頑張る理由もあるのですが… ねぇ。
そこで私は諦めました！ HomeApp でログインするプロトタイプにするのはやめました。
でも「Personium 使ったアプリ」を選択するのならあえてPDSで利用することもないですし… でも「Personium アプリ」でもない構造にすることにしました。
そこで…
###HomeAppのログイン機能（コード）を内包した「Personium アプリ」にしよ。 決定！！
そんなこんなで、プロトタイプ・アプリの作り込みに取り組むのですが、これを1から作ろうとするとやはり「Personium 使ったアプリ」的な方向に思考がすすみます。身体に染み付いているかのように。
そこで力になっていただけたのが ＠dixonsuiu さんでした。ありがとうございました！
ここで参考にしたのが、OSSチームが提供してくれている「template-app-cell」なのです。このアプリを自身のユニットにデプロイして、これに取り込まれている AppCell と Box をベースに、プロトタイプ・アプリを作り始めました。
#####しかし、このテンプレートアプリのデプロイ方法の手順が結構多く、手間取っていたのですが… ＠dixonsiu さん が以下のドキュメントを追加してくれて助かったのでした！ 感謝！！
※ そしてこのデプロイ中に、前のエントリの10番目の工程として記載した「personium-plugins のインストール」が Ansible には含まれておらず、デプロイした「template-app-cell」でエラーが出ることが判明し、解決方法をOSSチームに探っていただき解決しました。「template-app-cell」からいろいろ学ぼうとしている方は、「personium-plugins」のインストールを実施してください。
####そして、プロトタイプ・アプリに取り組む中で、事前に理解していた方がよいと思うのが、「Personium アプリ」と「Personium を使ったアプリ」の認証をメインとして表現したアクションフローです。
これを知ることにより、Personium の PDS としての価値を理解することができましたし、自分のプロトタイプ・アプリをどうしたいかを明確に把握し、誰がなんと言おうとまっすぐに進めるようになった気がします。
###「Personium アプリ」のアクションフロー
これが Personium の真髄なのかな？ と思われるようなフローになっていますよね。
アプリケーションは認証のことには全く触れず、アプリケーションロジックのみに集中できます。
そして認証やその後に一定期間で期限が切れる Token を再取得する機能である リフレッシュトークン を HomeApp がに担っているのでした。
これがアプリケーションを素早く簡単に構築できる基盤であり、強固なセキュリティを維持するための仕組みなのでした。 ようやく理解できました…
###「Personium を使ったアプリ」のアクションフロー
一方、「Personium を使ったアプリ」は認証機能を保持する必要があり、これは悪意を持った運営者が提供するアプリが、ログイン機能のなかでユーザーIDとパスワードを盗みとりストックすることが可能となります。
しかもそのような悪意がなかったとしても、Token の期限が来たら（ユーザーが意識しなくとも）再度 Token を取得する必要があり、そのためにはアプリの中に保持したパスワードがが必要で、自ずとアプリの中に保持する機能が必須となることがあり、PDSが要求するセキュリティ強度を守ることができないのかもしれません。
###私が構築した「プロトタイプ・アプリ」のアクションフロー
なのでやはり「Personium を使ったアプリ」選択しづらく、ほんの閃きのような、でも相当安直な折衷案な構造であるプロトタイプ・アプリのアクションフローが上記であり、善意をベースにアプリの中に HomeApp 機能を埋め込むという悪魔のような作業に取り組んでしまったのでしたぁ。
プロトタイプ・アプリについては、だいぶ後のエントリーの想定ではありますが、別の機会に詳細に説明しようかと計画はしています。 このエントリを上げた現時点のように、Personium についての情報を Qiita にあげることに興味を持ち続けられていれば、実現したいと考えています。
####乞うご期待！！
こんな内容で、Personium についての理解を深められたでしょうかね？？
エントリ内の文章はあまり気にしなくても良いですが、イメージで表現した内容はざっくりでよいので把握できていると Personium 初心者であってもアプリの構想をする間に、完成形のアプリについての構造を想定しやすくなるための、ほんのちょっとの手助けになるのではないかと考えます。
そうなっていれば幸いです… ね。
####メニュー
-
１０＜セルとボックスについて理解する＞
-
１１＜ホームアプリを触ってみる＞
-
１２＜ユニットマネージャって便利じゃん＞
-
１３＜テンプレートアプリってなんぞや＞
-
１４＜自分のアプリケーション＞