simplestarの技術ブログ

目的を書いて、思想と試行、結果と考察、そして具体的な手段を記録します。

ゲームデータの永続化

■前書き
しばらくぶりで記事の書き方を忘れてしまいました。

ここ最近は新たに Unity でゲームを作っていてちょうど見た目はこんな感じのサンドボックスゲームです。

f:id:simplestar_tech:20190321221355j:plain
テキトー

ゲームデータの永続化の部分を後回しにしたおかげで、後半になってスケジューリングまわりの挙動確認をしたり
どこにどうやってデータを置いて、これを引き出すべきか思案しなければならないことに(逆に最初からも難しいですが)

そこで最近 AWS の DynamoDB とか良いんじゃないかなって思い始めています。
高速読み書きできるオンラインデータベースです。

Unity での導入方法としてとても親切でわかりやすい記事も見つけました。
UnityでAWSを使うのはゼンゼンコワクナイヨー(シカモ無料デイケルヨ!) - Qiita

ちょっと触ってみようじゃないですか

追記:最終的に DynamoDB も遅くて話にならないから Cache サーバー(Redisとか)を使うことに決めてます。

■導入

Amazon Prime 契約されている方も多いかと思いますが
それより簡単に Amazon Web Services のアカウント登録が完了できます。

いざ、AWS 使うぞーと思ったら、どれにしますか?とこの画面が表示されます。

f:id:simplestar_tech:20190321223018j:plain
AWS 一覧

あまりに多く、AWS の人たちも全部に通じている人は少ないんだとか…
まずは認証認可の仕組みを学んで、ゲーム側からキーとなる文字列を使うとオンラインのデータベースを読み書きできるようにしてみようと思います。

参考記事では Cognito の ID プール使うとありますね。

AWS Cognito

f:id:simplestar_tech:20190321223528j:plain
AWS Cognito

ID プールボタンを押すことにしました。


認証プロバイダーに FacebookTwitter を選べるけど、コンシューマー登録IDとそれに関する秘密鍵を書き入れないといけないとある…
いきなり何してよいかわからなくなった、怖い…

ここで Cognito について基本的な部分を調べてみます。
AWS Cognitoについて調べてみた - Qiita

1.UserPoolにログインしてTokenを取得
2.取得したTokenをFederated Identitiesに渡す
3.Federated IdentitiesがTokenを検証
4.検証が完了したらSTSから一時クレデンシャルを取得
5.ユーザに一時クレデンシャルと統合IDを返す
6.統合IDと一時クレデンシャルを利用してAWSリソースにアクセス

確かにそうなんですけど…これだけではわからない
読んで得た知見:新出単語多くて、関連情報が引き出せただけでした。

上記用語と意味ですが、以下の参考リンクの方をすべて読む&理解したときにわかってきます。(結局全部読まないとダメでした)
よくわかる認証と認可
AWS Black Belt Online Seminar 2017 AWS Cognito
Amazon Cognitoによる認証はSTSのweb identity federationとどう違うのか!?

用語理解

認証:アクセスしてきた人が誰か特定すること(パスワードが合っていることを確認して認めるとか)
認可:認めた相手にオンライン操作を許可すること(権限の範囲を決めて、自由に操作させるとか)
OAuth: 歴史的に認証情報を渡さずに認可の権利だけ与える仕組みが流行り、そのときに色々取り決めた認証システム
MFA: 普通パスワードだけで入れるところ、指紋認証を加えるとか、パスポートのコピーを提出するとか、とにかく複数の要素で認証すること…あ、Multi(複数)-Factor(要素) AuthN(認証) の略字っぽい
認証しな認可ある?:あるっぽい、電車乗るのに切符買えばいい、誰でも切符あれば乗れる(は?切符持っているという要素を認証してない?)意味不明…と思いきや、誰でもいいというところが認証なしと言えるかも

認証は証明書を検証すること、認可は鍵を発行すること
参考:
よくわかる認証と認可 | DevelopersIO

ユースケースから見た AWS の Cognito

ユーザー認証を簡単に行いたい→ Congnito 使え
TwitterFacebook でログインしたい→ Cognito 使え
課金ユーザーにだけ限定コンテンツ配信したい→ Cognito 使え
オンラインサービスをユーザーにも提供したいがアクセスキーは提供したいくない→ Cognito 使え
デスクトップPCモニタ、ゲーム機画面、スマホ、ノートパソコンでまったく同じことしたい→ Cognito 使え

何度も同じこと書くようで悪いですが…
1.ユーザーデバイス上で Twitter にログインし、アプリで使う秘密の文字列(トークン)を取得
2.Twitter とかを認証プロバイダーと呼ぶことにして、それらを使わない場合は Cognito の User Pools にユーザーアカウント情報を記録するからこれを認証に使える?
3.とにかくトークンを取得する
4.そのトークンを Cognito の Identities に見せろ、一時的な認可の鍵を渡してもらえる
5.その鍵で許された範囲のオンラインコンテンツ操作が行える(期間限定で)

です。

用語確認:
認証 Provider:Twitter のユーザー名・パスワードなどでログインしてトークンを提供する人
Cognito Your User Pools : トークンを渡す人
IAM(アイアム): Cognito User Pool の User Group と認可の結合をする人
Cognito Identities : トークンをもらって IAM の通りの認可用の鍵を発行して渡す人
Temporry Credential : Cognito Identities からもらった一時的な認可用の鍵(ログインしてトークン得て、トークン渡して手に入れる一時的な鍵)

サービス提供者が行う具体的な準備

Cognito で User Pool を作成する
Cognito で Identity Pool を作成する
Cognito で User Pool と Identity Pool を結合
IAM で Identity Pool に許可する操作を追加
専用 SDK 使ってクライアントデバイスから、ログイン→トークン取得→Temporary Credential取得のコードを実装する
その Temporary Credential を使って AWS リソースを操作(例えば DynamoDB への書き込み)を行うコードを実装する

と言った内容をイメージしたが、合っているのかな?

参考:
AWS Black Belt Online Seminar 2017 AWS Cognito


…ここも読むしかなさそうだな
Amazon Cognito(ウェブ/モバイルアプリのユーザー管理)| AWS

読んで得た知見:外面だけの文言も、また前提知識を求めるものばかりで要点がつかめない…

仕方ない、やっぱりここを全部読みます。(途中で日が暮れたのでやめました…)
Amazon Cognito とは - Amazon Cognito

ディレクトリって何をイメージすればいんですか?

2004年の記事ですが、こちら読みました。
ユーザー・アカウントを一元管理できる「認証ディレクトリ」に注目
認証を一回にする、簡単にするために、みんなで一緒のものを使おう…おれのシステム使えー!という戦国時代があったんですね…という感想を得ました。
WebシステムやC/Sシステムなどが混在した環境でアカウントの一元管理をするため考え出されたもの、それが「認証ディレクトリ」だ
一元化したユーザー情報のことを「ユーザー情報」と呼ばずに「ディレクトリ」と呼ぶことにしたらしい。なんで?
すべてのユーザーのアカウント情報を集め、管理するシステムを「統合ディレクトリ」とも呼ぶ、なんで?
クライアントマシンにエージェントと呼ばれるサービスを忍ばせて、統合ディレクトリからID・パスワードを取り出して、勝手にサイトへアカウント情報を送信する仕組みらしい。
なのでエージェントを仕込めば、ユーザーはID・パスワードの入力から解放されるそうな
安全ですね!

関連してプロビジョニング(Provisioning)という用語も理解しようと思う
…セキュリティの確保という意味らしいが、具体的にはユーザー・アカウントのライフサイクル(生成/配布/更新/廃棄あるいは失効)を管理/運用する機能のことをさす

歴史的に 2004 年頃はまだ統合ID管理製品が発展途上期だった様子
なるほど、知らずに高校生やってたぜ…

公式ドキュメントの本文にもどります

Amazon Cognito は、SOC 1~3、PCI DSS、ISO 27001 に準拠し、HIPAA-BAA に対応しています。

わかんねーよ(笑)
公式ドキュメントのこういう専門用語理解できないと何もわからなくするように突き放す文章スゲーと思うよ。
わざとわからなくするドキュメントコンテストで公式ドキュメント群は全部上位取れるよw

結局概要をつかんでみてわかったのはユーザープールとIDプールの二つがあって
ユーザープールがアカウント情報を管理するシステム
IDプールがサービスごとのアクセス権限を管理するシステム
アプリ実装するときはユーザープールにIDとパスワード送ってトークンを取得するように記述し
そのトークンをIDプールに渡して、一時的認証情報に交換してもらい
その一時的認証情報をSDKに渡せばAWS操作できるよ、ということだった。

具体的な手順は、まずは一個簡単なプロジェクト作るところからどうぞ…とのことなので、次のサンプル手順をなぞってみることにします。
開発者用リソース - Amazon Cognito | AWS

次の記事へ続く
AWS DynamoDB を Unity で操作する - simplestarの技術ブログ