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

本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン（SSO）ソフトウェア「Keycloak」の活用方法を解説していきます。Keycloakの認可サービスを利用することで、アプリケーションに対して、より細やかで柔軟なアクセス制御を実現することが可能です。前編、後編の2回に分けて、その方法を解説します。

[和田広之, 相田洋志, 田村広平, 上田直樹, 青柳隆，野村総合研究所／野村総合研究所／フリーランス／株式会社リック／フリーランス]

連載目次

本稿で紹介したDocker環境は、以下のGitHubで公開しています。すぐに動かすことができますので、こちらもぜひご参照ください。

• https://github.com/openstandia/keycloak-dockerfiles

はじめに

　通常、Webアプリケーションではユーザーの権限に応じてなんらかのアクセス制御を行います。本連載第7回「Keycloakで実用的なリバースプロキシ型構成を構築してみよう」では、ユーザーが管理者のロールを持っているかどうかによって、管理者用のパスのアクセス制御を行う例がありました。

　このようなシンプルなアクセス制御であれば、リバースプロキシ型でも実現可能ですが、アプリケーションに複雑なアクセス制御の要件があると実現が難しい場合があります。

　このような場合に、Keycloakのクライアントアダプターの認可機能を利用することで、より細やかで柔軟なアクセス制御が実現できるようになります。

　OpenID Connect用のクライントアダプターのうち、Javaアダプターでは以下のミドルウェア用のモジュールが提供されているため、これらのミドルウェアで動作しているアプリケーションに対して、認可サービスが利用可能です。

• WildFly
• JBoss EAP
• JBoss Fuse
• Jetty
• Apache Tomcat

　今回は、認可サービスのうち、システム管理者によってアクセス制御を集中管理する方式について、実機での動作も確認しながら、解説していきます。

Keycloakの認可サービスとは？

　Keycloakの認可サービスには、以下の2つのアクセス制御方式があります。

• システム管理者によってアクセス制御を集中管理する方式
• エンドユーザー（リソースオーナー）自身でアクセス制御を行う方式

　本稿では便宜上、前者を「集中管理方式」、後者を「UMA（User-Managed Access）方式」と呼ぶことにします。2つの方式の大まかな違いは、表1の通りです。

	集中管理方式	UMA方式
アクセス制御の設定者	システム管理者	エンドユーザー
エンドユーザー主体のリソースの共有	不可能	可能
エンドユーザー主体の パーミッションの申請／承認／却下	不可能	可能
アプリケーション改修の必要性	必要なし（※）	必要あり
表1　アクセス制御方式の主な違い （※）アプリケーション内でログインユーザーの情報を取得するコードなどは必要です。

集中管理方式とは？

　集中管理方式は、システム管理者がKeycloak上にあらかじめアクセス制御のルールを設定しておき、そのルールに基づいてアクセス制御を行う方式です。いわゆる、集中管理型のアクセス制御方式になります。

　システム管理者がアクセス制御を集中して管理できるのはメリットでもありますが、アクセス制御の変更をシステム管理者に依存することになります。

　Keycloakで集中管理方式のアクセス制御を利用する場合には、「リソース（URI）」と「ポリシー（判定条件）」を網羅的に定義していきます。そして、定義したリソースとポリシーを関連付けた「パーミッション（リソースとポリシーの関連付け）」を作成することで、アクセス制御のルールを設定することになります。

　Keycloak上のリソース、ポリシー、パーミッションの関係性については、図1のようになります。リソースとパーミッションは1対1で、パーミッションとポリシーは1対多で関連付けられます。

図1　アクセス制御の関係性

（※）リソースには、任意のリソースタイプ（複数のリソースをグループ化するキーワード）を設定できます。パーミッションはリソースタイプとも関連付けを行うことができるので、結果的にパーミッションに複数のリソース（同じリソースタイプを持つリソース群）を関連付けることが可能になります。この場合、リソースとパーミッションの関係は多対1となります。

　Keycloakのポリシーでは、表2の7つのメカニズムが利用できます。このメカニズムを利用して、リソースへのアクセスを制御できます。

メカニズム	条件判定元
属性ベースアクセス制御（ABAC）	ユーザーの属性値
ロールベースアクセス制御（RBAC）	ユーザーのロール、もしくはグループ
ユーザーベースアクセス制御（UBAC）	特定のユーザー
コンテキストベースアクセス制御（CBAC）	OAuth2アクセストークンや、実行環境（クライアントIPや、メソッド、URIなど）
ルールベースアクセス制御	JavaScriptやJBoss Drools（ビジネスルール管理エンジン）の実装
時間ベースアクセス制御	特定の日付、時間
上記以外の独自アクセス制御	ポリシーのカスタマイズ実装に依存 （※本稿では言及しません）
表2　ポリシー一覧（参照元：https://www.keycloak.org/docs/latest/authorization_services/index.html#_overview）

●集中管理方式の認可シーケンス

　集中管理方式でアクセス制御を行う場合の動作シーケンスは、図2のようになります。

図2　集中管理方式の認可シーケンス（このシーケンスは簡略化して記載しているため、実際の挙動はもう少し複雑です）

（1）クライアントアダプターがKeycloakからリソースの一覧（リソースIDの配列）を取得します。

（2）クライアントアダプターが（1）のリソースの一覧を使って、Keycloakからリソースの詳細（名前、URI、リソースタイプなど）を取得します。ここで取得したリソースの詳細により、アクセス可否の判定が必要なURIをクライアントアダプターが認識します。

（3）エンドユーザーがOpenID Connectの認証処理を行います（認証処理に関しては、本連載第7回のシーケンス図1.〜12.と同様なので、ここでは省略します）。

（4）エンドユーザーが保護リソースにアクセスします。

（5）エンドユーザーがセキュリティトークンを持っていない、もしくはセキュリティトークンの有効期限が切れている場合、クライアントアダプターがKeycloakにアクセス可否の問い合わせを行います。有効なセキュリティトークンを既に持っている場合には、アクセス可否の問い合わせはせずに（7）に遷移します。

（6）Keycloakがクライアントアダプターにアクセス可否結果を返します。許可であれば、200応答でセキュリティトークンが返ります。拒否の場合は、403エラーになります。

（7）認可アプリがアクセス可否結果を元に、保護リソースの表示有無を切り替えます。