Keycloakで認可サービスを試してみよう［後編］：Keycloak超入門（最終回）（1/3 ページ）

連載目次

はじめに

　前回の第8回では、「Keycloak」の認可サービスのうち、「集中管理方式」について解説しました。集中管理方式では、アクセス制御の管理をシステム管理者が行う「システム管理者中心のアクセス管理」を実現しました。

　今回解説する「UMA方式」では、「UMA（User Managed Access）」というプロトコルを使用してアクセス制御の管理をエンドユーザー自身が行う「エンドユーザー（リソースオーナー）中心のアクセス管理」を実現します。この方式を適用することにより、エンドユーザー自身で、リソースを他者と共有設定することや、パーミッションの認可ワークフロー（パーミッションの申請／承認／拒否）を利用することができるようになります。

　ただし、UMA方式では、Keycloakやクライアントアダプターの設定以外にも、アプリケーション側へ追加の実装が必要になってくるため、集中管理方式に比べると難易度が高く、開発者の負担も多くなります。本稿では、UMA方式の実際の動作を通して、どのような設定や実装が必要になるかを解説していきます。

UMA（User-Managed Access）方式とは

　第8回でも少しだけ触れましたが、UMA方式は「エンドユーザー（リソースオーナー）自身でアクセス制御を行う方式」のことです。そもそも、このUMAは、ID管理技術の相互運用を目指す業界団体「Kantara Initiative」によって標準化が行われているOAuthの拡張の一つです。

　OAuthはリソース管理者がクライアントのアクセスを限定的に認可するためのプロトコル（フレームワーク）ですが、リソース管理者とは別の人物が操作するクライアントに対するユースケースなどは特に規定していません。一方、UMAはそのようなユースケースなどをカバーするためにOAuthを拡張し、設計されたプロトコルになりますUMAの詳しい説明についてはこちらの記事（＠ITの記事／IPAの技術動向調査）を参照してください。

　UMAを利用することにより、オンラインサービスで提供される各種リソースについて、エンドユーザー（リソースオーナー）自身で、他者や他サービスに対して柔軟なアクセス制御が行えるようになります。つまり、UMAはユーザー主導で動的なアクセス制御が必要となるアプリケーション（特に疎結合なAPIサービスなど）への適用に向いています。逆に言えば、アクセス制御が一定でほとんど変わらないようなアプリケーションでは使う必要のない方式であり、第8回で解説した集中管理方式が適しています。

　今回説明するUMA方式のユースケースを例にとり、図1で各アクターとそれぞれの関係性について、表1で各アクターの役割について説明します。

図1　UMAのアクターとそれぞれの関係性

UMA方式の認可シーケンス

　UMA方式でアクセス制御する場合の動作シーケンスの例を以下の図2、図3に示します。図2は、リソース共有時のシーケンス、図3は、パーミッションの申請／承認のシーケンス図になります。なお、図3のパーミッションの申請／承認部分に関しては、UMAの仕様として定義されているものではなく、KeycloakのUMA方式での独自仕様になっています。そのため、認可サーバとしてKeycloakを使用する場合のユースケースの一例として解説します。

図2　UMA方式のリソース共有時の認可シーケンス

図3　UMA方式のパーミッション申請／承認時の認可シーケンス

　以上がUMA方式の概要です。

認可サービスの動作環境の構築

　ここからはUMA方式が動作するDocker環境を使い、実際の動きを確認しながら、UMA方式についての理解を深めていきたいと思います。第8回と同じ環境を利用してUMA方式の動作検証をするため、構築手順については割愛させていただきます。まだ環境を構築されていない方は第8回の記事を参考に構築してください（※第8回のアーカイブから一部内容を変更しているため、既にダウンロード済みの方も新たなDockerビルドファイルでの構築をお願いいたします）。こちらの環境を利用して、図2、図3のシーケンス図で示したようなUMAの基本的な認可フローの動作を確認していきます。

　以降、掲載記事ボリュームの都合上、説明を省略した部分も多くあります。UMAの仕様やKeycloakのガイド、Docker環境などを適宜参照しながら、UMAについての知見を深めていただければと思います。

図4　今回構築する検証環境の構成

　次に構成するDockerコンテナは、表2のようになります。

　UMA方式の動作確認で利用するコンテンツ／APIは、表3のようになります。

UMA方式の動作確認

　それでは、UMA方式の実際の動作を確認していきましょう。今回の検証では、大きく分けて、以下の3つのシナリオがあります。

［1］リソースの作成
　リソースオーナー（user001）が、リソースサーバにリソースを作成する操作を確認します。リソースサーバ側にリソースの実体が作成されるのと同時に、Keycloak側にもリソース情報の登録が行われます。

［2］リソースの共有／共有解除
　リソースオーナー（user001）が、自身のリソースをリクエスティングパーティー（user002）に共有／共有解除する操作を確認します。この共有操作により、user002がuser001のリソースにアクセスした際の挙動が変わることを確認します。

［3］リソースへのパーミッションの申請／承認／拒否
　リクエスティングパーティー（user003）が、リソースオーナー（user001）のリソースに対して、パーミッションの申請を行います。user001がこのパーミッション申請を許可することにより、user003がuser001のリソースにアクセスした際の挙動が変わることを確認します。

　以降の動作確認では、前出の図2、図3のシーケンス図と見比べながら、動作確認を行うと流れが理解しやすいです。シーケンス図上のユーザーAは「user001」、ユーザーBは「user002」、ユーザーCは「user003」に対応しています。

［1］リソースの作成

【リソースオーナー（user001）の操作】
　1.Webアプリ（http://uma.example.com/authz-uma-client/）にアクセスします。

　2.user001でログインします。

　3.Webアプリのトップ画面（リソース一覧）が開きます（画面1）。この時点では、user001に何もリソースが作成されていない状態です。

画面1　Webアプリのトップ画面

　4.「リソース管理」プルダウンから「リソースの共有／申請の確認・承認」をクリックすると、Keycloakの「マイリソース」画面が開きます（画面2）。この時点では、ログインユーザーが所有しているリソースはないことが分かります。

画面2　Keycloakの「マイリソース」画面（リソース作成前）

　5.画面右上の「authz-uma-clientに戻る」を押して、Webアプリに戻ります（画面3）。

画面3　Keycloakの「マイリソース」画面

　6.「リソース管理」プルダウンから「リソースの新規作成」をクリックします。「リソース名」「メモ」を入力可能な画面が表示されます（画面4）。ここではリソース名に「user001 Item」という文字を入力して、「リソースの作成」ボタンをクリックします。正常にリソースが作成されると、「簡易メッセージ」に「リソースが作成されました！」というメッセージが表示されます（画面5）。

画面4　リソースの新規作成

画面5　リソースの新規作成完了

　7.フッター部の「リソース一覧に戻る」のリンクをクリックすると、画面上に作成したリソースへアクセスするリンクが表示されるようになります。自分のリソースに対しては、どの操作も問題なく実行できることを確認できます（自身が所有するリソースに対しては、「リソース操作」ボタンは白色で表示され、権限申請のボタンは表示されません）。

　8.リソース作成後に「マイリソース」画面がどのように変わったかを確認するため、再び、「リソース管理」プルダウンから「リソースの共有／申請の確認・承認」をクリックします。先ほどとは異なり、マイリソースに「user001 Item」というリソースが表示されていることが分かります（≪≫画面6）。

画面6　Keycloakの「マイリソース」画面（リソース作成後）

　9.画面右上の「authz-uma-client に戻る」を押下して、Webアプリに戻ります。

　10.「ログアウト」して、user002、user003でも同様にリソースの作成操作を行っておきます。

［2］リソースの共有／共有解除

【リクエスティングパーティー（user002）の操作】
　1.user002でWebアプリにログインします。

　2.「user001 Item」の「参照」「削除」の操作を行ってみます（画面7）。いずれも、401 errorが発生し、全ての操作が拒否されていることを確認できます（自身が所有しないリソースに対しては、「リソース操作」ボタンは青色で表示され、権限のない操作に関しては、それぞれの権限申請のボタンが表示されます）。

画面7　他者のリソースへのアクセス拒否

【リソースオーナー（user001）の操作】
　3.「マイリソース」を押下し、リソースの「user001 Item」を押下します。現在のこのリソースにアクセスできるユーザー一覧や、他者と共有するための「共有」ボタンが表示されます。

　4.ここで「他人と共有」の「ユーザー名 or Eメール」に「user002」を指定し、リソースの削除権限である「item:delete」の「×」をクリックした後で「共有」ボタンをクリックします（画面8）。

画面8　別ユーザーとのリソース共有操作

　5.「このリソースにアクセスできる人」の中にuser002が追加され、許可されている操作は「item:update」と「item:view」になっていることを確認できます（画面9）。

画面9　共有後の「user001 Item」の表示

【リクエスティングパーティー（user002）の操作】
　6.「user001 Item」の「参照」「更新」「削除」の操作を行ってみます。先ほどとは異なり、「参照」「更新」は「200 success」が返り、user001により共有された操作（item:viewとitem:update）だけが許可されていることが分かります。削除（item:delete）に関しては、401 errorが発生し、アクセスが拒否されていることが分かります（画面10）。

画面10　リソース共有が適切に動作した結果

［3］リソースへのパーミッションの申請／承認／拒否

【リクエスティング・パーティー（user003）の操作】
　1.user003でWebアプリにログインします。

　2.「user001 Item」の「参照」「削除」の操作を行ってみます。いずれも、401 errorが発生し、全ての操作が拒否されていることを確認できます。

　3.「user001 Item」の「権限申請」から、「参照権限申請」と「更新権限申請」をクリックします（画面11）。

画面11　「user001 Item」の「更新権限申請」のパーミッション申請の呼び出し

　4.「リソース管理」プルダウンから「リソースの共有／申請の確認・承認」をクリックします。「承認待ちのリクエスト」にuser001に対して、パーミッションが申請中の状態になっていることを確認できます（画面12）。

画面12　承認待ちリクエストの表示

【リソースオーナー（user001）の操作】
　5.「リソース管理」プルダウンから「リソースの共有／申請の確認・承認」をクリックします。「承認が必要」にuser003から「item:view」と「item:update」のパーミッションが申請されていることを確認できます（画面13）。

画面13　パーミッション申請の承認画面

　6.「item:update」を削除した上で、「承認」ボタンをクリックします。

【リクエスティングパーティー（user003）の操作】
　7.「user001 Item」の「参照」「更新」「削除の操作を行ってみます。先ほどとは異なり、「参照」は、200 successが返り、「更新」「削除」に関しては、アクセスが拒否されます（画面14）。申請した操作のうち、user001が許可した操作（item:view）だけが、許可されていることが分かります（画面15）。

画面14　アクセス申請が許可された後の「user001 Item」の参照操作

画面15　アクセス申請が許可された後の「user001 Item」の更新操作