マイクロサービス時代のSSOを実現する「Keycloak」とは：Keycloak超入門（1）

本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン（SSO）ソフトウェア「Keycloak」の活用方法を解説していきます。第1回目は、APIにおける認証／認可の仕組みとKeycloakの概要を紹介します。

[茂木昂士，株式会社日立製作所]

連載目次

APIにおける認証／認可の仕組み

　近年、金融や流通分野で注目されている「APIエコノミー」や「マイクロサービスアーキテクチャ」などの登場により、サービスの機能を「REST API」として提供することが当たり前になってきています。そして、REST APIを公開するためには、誰がアクセスしてきたのかを確認するための「認証（Authentication）」と、APIへのアクセスを誰に許可するのかという「認可（Authorization）」の仕組みが不可欠です。

　しかし、複数のサービスがそれぞれ個別に認証／許可を行うと、ユーザー名／パスワードといった認証情報やアクセス制御ポリシーの管理が煩雑になってしまいます。そこで、一度の認証で全てのサービスを利用できるようにする仕組み「シングルサインオン（SSO）」が有用になってきます。

　これまでの認証／認可のアーキテクチャでは、1つのサービスで認証を行った結果を「セッション」として保持しておき、そのセッションを用いてアクセスを制御すれば問題ありませんでした。ところが、マイクロサービスアーキテクチャのように複数のサービスが協調して動作するようなアーキテクチャでは、サービスごとに認証／認可を行う必要があるため、認証情報やアクセス制御ポリシーの管理が煩雑になってしまいます。

　そこで、認可と認証の機能をAPIサーバから分離し、ユーザーが“認証済み”であることを示す認証結果やアクセス権限などの認可情報をAPIサーバ間で共有することで、認証情報やアクセス制御ポリシーを一元化し、管理を容易にすることができます（図1）。

図1　認可と認証の機能をAPIサーバから分離し、認可情報をAPIサーバ間で共有することで、管理を容易にする

　ここで「認可情報」をやりとりするには、APIサーバ、エンドユーザー、認可プロバイダーの間で手順を決める必要があります。この手順を定めたプロトコルの最も有名なものとしては「OAuth」があります。

　OAuthはWebアプリケーションによる認可を行うためのオープンなプロトコル標準であり、多くのWebサービスで利用されています。OAuthでは「認可プロバイダー」と呼ばれるアプリケーションが、認可を受けるアプリケーションに対してアクセストークンを発行します（図2）。アプリケーションはそのアクセストークンを用いることで、APIへのアクセスが許可されます。

図2　OAuthでは「認可プロバイダー」が、認可を受けるアプリケーションにアクセストークンを発行する

　しかし、OAuthでは、アクセストークンが誰に対して発行されたのかは仕様に規定されておらず、これにより“トークン横取り（authorization code interception attack）”による攻撃が可能になる他、規定があいまいであることからセキュリティに問題が生じてしまいます。

　このような問題を抱えるOAuthを補完するシンプルで安全な認可の仕様として「OpenID Connect（以下、OIDC）」が注目されています。OIDCはOAuthによる認可に加え、「ID Token」という検証可能なトークンを利用しています。ID Tokenには「JSON Web Token（JWT）」という改ざん耐性のある仕組みが用いられており、サービス間で認証済みユーザーやトークン発行対象などといった認可情報を安全に共有できるようになります。

認可オープンソースソフトウェアの動向

　OIDCによる認可を利用してAPIを公開する場合、ID Tokenの発行を行う認可プロバイダーの構築と、APIサーバによるID Tokenを検証する機能の追加が必要になります。これらの機能を構築するために、これまではパッケージソフトの利用がほとんどでした。しかし、近年ではオープンソースソフトウェア（OSS）も商用製品と同等レベルになってきており、有力な選択肢となっています。以下にOIDCの認可プロバイダーとして動作する主なOSS実装の概要を示します。

OpenAM

　「OpenAM」はSun Microsystemsの「OpenSSO」を基盤に開発された、Javaベースの認証ソフトウェアです。商用製品として開発されていたため、信頼性／安定性が高く、導入実績も豊富です。

　しかし、2017年7月現在、古いバージョンのソースコードのみが公開されているだけで、コミュニティーベースの開発は行われていません。また、フォーク（fork：分岐）の動きも見られ、OSSとしての今後が不透明な状況であるため、取り扱いには注意が必要でしょう。なお、商用版については、現在も複数の企業より継続的に開発、提供が進んでいます。

Gluu Server

　「Gluu Server」は小規模コミュニティーながら、活発な開発が進められているソフトウェアです。特にクライアント向けライブラリが充実しており、さまざまな言語やフレームワークにライブラリを提供しています。

Keycloak

　「Keycloak」は比較的新しいソフトウェアで、現在活発に開発が行われているオープンソースプロジェクトです。OAuth／OIDCに対応し、特にOIDCについてはOpenID Foundationが行っているCertification Programにおいて、全てのプロファイルの認定を取得しています。商用ではRed Hatによる有償版が提供されており、対策版提供までを含む手厚いサポートがあります。コミュニティーの活性度も高く、将来性が有望なOSSであるため、本稿では主にKeycloakの解説を進めます。

Keycloakの機能

　Keycloak（http://www.keycloak.org/）は、ミドルウェア型の認可機能やアイデンティティー（ID）管理機能を備えるOSSであり、1〜2カ月に1回程度でマイナーバージョンアップが行われています。2017年7月時点の最新バージョンは「3.2.0.Final」です。

　Keycloakが提供する主な機能は表1の通りです。これらの機能は、クライアントアダプター、クライアントプロキシを除き、全てアプリケーションサーバ上のアプリケーション（以下、Keycloakサーバ）として提供されています。

分類	機能	詳細
認証	自身での認証	ユーザー名認証やワンタイムパスワードなど、複数の認証を組み合わせることができる
	ディレクトリサーバ連携	OpenLDAPやActive Directoryといったディレクトリサービスと連携できる
	外部IdP連携	OpenID Connectに対応したIdentity Provider（IdP）に接続できる
認可	認可プロバイダー	OAuthやOIDCといった一般的なAPI認可プロトコルに対応。Webサービスベースの認可（SAML）にも対応する
	クライアントプロキシ	リバースプロキシとして動作し、バックエンドのアプリケーションに対してOAuth／OIDCによるアクセス制御を可能にする
	クライアントアダプター	クライアント側アプリケーションでの認可取得やアクセス制御といった機能を、複数のフレームワークに対するライブラリの形で提供している
表1　Keycloakが提供する主な機能

Keycloakによる認証

　KeycloakはID管理機能を備えており、ユーザー認証を行うことができます。ユーザー認証には、Keycloak自体が持つ認証機能の他、ディレクトリサービスとの連携や外部のIdentity Provider（IdP）を利用することもできます。

• 多要素認証

　Keycloakではユーザー／パスワードによる認証だけでなく、ワンタイムパスワードなどを組み合わせた「多要素認証」を実装することができます。

• 外部IdP連携

　GoogleやFacebookといったOIDCのIdPとして機能するサービスと連携することで、認証を外部に委譲することができます。また、外部サービスを利用するだけでなく、他のKeycloakサーバやOIDCに対応したIdPとも連携できます。

• ディレクトリサーバ連携

　KeycloakはOpenLDAPやActive Directoryといったディレクトリサービスに接続することで、既存のユーザー情報をKeycloakに統合することができます。統合の際には、Keycloakが管理するユーザーの属性と、ディレクトリサービスの識別名のマッピングを設定することで、既存の情報をKeycloakに統合し、ユーザーの認証を外部に委譲することが可能になります。標準では、LDAP（Lightweight Directory Access Protocol）およびKerberosに対応したディレクトリサービスと連携できます。

Keycloakによる認可

　KeycloakはOAuthやOpenID Connectといった、主要なAPI認可プロトコルのプロバイダーとして機能し、サードパーティーアプリケーションに対するアクセス制御を行うことができます。API認可以外にも、Webサービスベースの認可プロトコル（SAML）にも対応しています。

• 認可プロバイダー

　KeycloakはOAuthの認可サーバや、OpenID ConnectのIdPである認可プロバイダーとして機能し、サードパーティーアプリケーションへのアクセストークンの発行やAPIサーバへのアクセス制御などの機能を提供します。これらの設定はWeb GUIやWeb API経由で行うことができます。

• クライアントプロキシ

　クライアントプロキシはHTTPのリバースプロキシとして動作し、クライアントアダプターを適用できないバックエンドのアプリケーションに対してOAuth／OIDCによるアクセス制御を提供します。

• クライアントアダプター

　Keycloakでは、クライアントアダプターと呼ばれるライブラリを提供しています。クライアントアダプターをアプリケーションやサーバに適用することで、Keycloakを認可サーバ、IdPとした認可処理やアクセス制御を実現できます。

Keycloakの動作環境

　Keycloakの動作には512MB以上のメモリと、1GB以上のディスク容量が必要です。また、前提として以下のコンポーネントが必要になります。

コンポーネント	推奨
Java	Oracle JDK 8またはOpen JDK 8
アプリケーションサーバ	JBoss EAPまたはWildfly
データベース	H2 Database、PostgreSQL、MySQL、OracleなどのRDBMS

API公開におけるKeycloakの役割

　Keycloakが備えるOAuth／OIDCの機能を利用することで、保護されたリソースを安全にAPIとして公開できるようになります。以降は、OIDCを利用したAPIの公開例を説明します（図3）。なお、ここではOAuthで定義されている4つのグラントタイプのうち、認可コードグラント（Authorization Code Flow）によるアクセスについて説明します。詳細はRFC 6749を参照してください。

図3　OIDCを利用したAPIの公開例

　（1）ユーザーはKeycloakのログイン画面にアクセスし、Keycloakに登録されているユーザー／パスワードでログインする（もしくは、外部のLDAPサーバと連携しての認証も可能）。ログインが成功すると、Keycloakは「認可コード」という値をユーザーに与える。

　（2）ユーザーはサードパーティーアプリケーションに対して、認可コードを付加したアクセスを行う。

　（3）サードパーティーアプリケーションは、認可コードを元にKeycloakからアクセストークンを要求する。認可コードを含む要求が正しければ、Keycloakはアクセストークンを返却する。

　（4）サードパーティーアプリケーションは、APIサーバにアクセスする際に、取得したトークンを要求に含める。

　（5）APIサーバでは送られてきたアクセストークンの内容をチェックするため、Keycloakに検査要求を行う。この検査要求はクライアントアダプターが処理する。アクセストークンの内容が正しければ、サードパーティーアプリケーションにレスポンス内容を返却する。

　以上のように、ユーザーの認証情報管理やアクセストークンの管理、アクセス制御などの処理は、Keycloakおよびクライアントアダプターに委譲することができるため、APIサーバは必要最小限の設定でOIDCによるアクセス制御を実現できるようになります。

　次回はKeycloakのサンプルアプリケーションを利用して、Keycloakの簡単な使い方の説明と、KeycloakによるAPI認可処理の動作を検証します。

筆者紹介

茂木 昂士（もぎ　たかし）

株式会社日立製作所 OSSソリューションセンタ所属。これまではソフトウェアエンジニアとしてストレージやサーバの管理ソフトウェア開発に従事してきた。現在は、主にアイデンティティー管理OSSやAPI管理OSSの検証、導入支援を行っている。