こんにちは、新卒エンジニアの中村です。

Web業界では、常に新しい技術や技法が生まれたりしてますね。そのなかでは、残念ながら実務では使わないものも多くあるとは思うのですが、これからの時代で標準となっていく可能性の高い技術も多く見られるので、ITエンジニアのはしくれとして是非ともキャッチアップしていきたいものです。

今回は、近年注目を集めているマイクロサービスについて、ユーザー認証の管理をしてくれる便利OSS「Keycloak」をご紹介します！

さて、近年、Web業界ではマイクロサービスと呼ばれる開発手法が非常に注目を集めていますね。
マイクロサービスとは、Webサービス上の全ての機能を一つのプロジェクトとして開発していくいわゆる「モノリシック」な開発手法とは対照的になるものです。すなわちマイクロサービスでは、Webサービスの一つ一つの機能を分解して各々を小さなWebサービスとして機能するように開発を行い、それらを連携させることで全体として大きなWebサービスが機能するように設計を行う、というわけです．．．。

より具体的に言うと、従来的なモノリシックな開発では、UIもビジネスロジックもWebサービスの全部が一体となったひとつのアプリケーションとして本番環境のサーバ上で動いています。マイクロサービスでは、UIもビジネスロジックも、より細かい機能単位で分割した上で、アプリケーションとして動作させ、それらをREST APIで連携させることで、全体としてWebサービスとして機能させるイメージです。

また、マイクロサービスのもう一つの特徴は、それぞれのアプリケーションがコンテナ上の仮想環境で実行されることです。そのため、それぞれのアプリケーションでそれぞれ自由に異なる言語やフレームワーク、DBなどを採用したり、Webサービス全体をKubernetesで管理することで、デプロイやスケール、負荷分散等の自動化が可能になります。
マイクロサービスのメリットデメリットは非常に多く議論されており、ここでは全てを挙げられません。
また、全ての現場において採用するべき技術というわけでもないのですが、これからの時代、大規模化、複雑化していくアプリケーションを効率よく開発していく上では必須な技術のように思えますね。

それではそろそろ本題に移ります。
マイクロサービスでは、どのようにユーザー認証を管理していけばよいでしょうか。モノリシックなサービスであれば、これは単純にログインに成功したユーザー情報をセッションに登録して管理するだけでそれぞれのユーザに対し適切なサービスを提供出来ます。ですが、マイクロサービスはそれぞれの機能がアプリケーションとして独立しているため、セッションにログイン済みユーザー情報を登録したところで別の機能からはそのセッションは参照出来ません。その前に、そもそも各機能をREST APIで設計する前提なので、セッションを使うこと自体がご法度です。そこで、Webサービスの設計にもよりますが、一般的にはユーザー認証を中央集権的に提供するサービスを用意する必要が出てきます。ただし、このユーザー認証の機能に関してはいちから自らで実装する必要はないです。なぜなら「Keycloak」というOSSがユーザー認証まわりの一通りの機能を実装しており、Keycloakをマイクロサービスの一部として導入するだけで問題が解決するからです．．．。

というわけで、今回の記事の主旨であるKeycloakを試しに動かし、その便利さを実感したいと思います。

Keycloakとは、RESTfulなWebサービスに対してユーザー認証の仕組みを一通り提供しているOSSです。
提供している機能を公式ドキュメントから引用しますが、以下の通りです。

・ブラウザー・アプリケーションに対するシングル・サインオンとシングル・サインアウト。

・OpenID Connectのサポート。

・OAuth 2.0のサポート。

・SAMLのサポート。

・アイデンティティー・ブローカリング – 外部のOpenID ConnectもしくはSAMLに対応したアイデンティティー・プロバイダーによる認証。

・ソーシャル・ログイン – Google、GitHub、Facebook、Twitterや他のソーシャル・ネットワークによるログイン。

・ユーザー・フェデレーション – LDAPやActive Directoryからのユーザー同期。

・ルベロス連携 – ケルベロス・サーバーにログイン済のユーザーに対する認証連携。

・ユーザー、ロール、ロール・マッピング、クライアントと設定を一元管理するための管理コンソール。

・ユーザーに自分達のアカウントを一元管理することを許可するためのアカウント管理コンソール。

・テーマ対応 – すべての利用者向け画面をカスタマイズでき、アプリケーションとブランディングを統合可能。

・二要素認証 – Google AuthenticatorやFreeOTPを使用したTOTP/HOTPのサポート。

・ログイン・フロー – オプション機能のユーザー・セルフ・レジストレーション、パスワード・リカバリー、電子メールによる検証、強制パスワード変更など。

・セッション管理 – 管理者や利用者が自分のセッションを参照・管理することが可能。

・トークン・マッパー – ユーザー属性やロールなどをトークンやステートメントにどのように反映するかの指定。

・レルム、アプリケーション、ユーザー単位のNot-beforeリボケーション・ポリシー。

・CORSのサポート – CORSに対応済みのクライアント・アダプター。

・サービス・プロバイダー・インターフェイス（SPI） – サーバーのさまざまな側面をカスタマイズするための数多くのSPI。認証フロー、ユーザー・フェデレーション・プロバイダー、プロトコル・マッパーなどその他多数。

・JavaScript、WildFly、JBoss EAP、Fuse、Tomcat、Jetty、Springなどのクライアント・アダプター。

・OpenID Connectのリライング・パーティー・ライブラリー、もしくは、SAML 2.0のサービス・プロバイダー・ライブラリーをもつ、あらゆるプラットフォーム/言語のサポート。

・なんか色々なログイン手段とユーザー認証の手段が提供されていますが、今回はその中でも一般的なブラウザからのシングルサインオンとOpenID Connectの認証フローを使ったうえで、以下の動作を確認してみたいと思います。

・Keycloakの起動

・OpenID Connectに対応したデモ用のWebアプリを起動（なるべくお手軽な方法で．．．）

・Keycloakとデモ用WebアプリでOpenID Connectのフローが試せることを確認

その前にOpenID Connectとは何かご紹介します。
以下に、OpenID Connectを使ったユーザー認証＆ユーザー許可のフローを記載しておきます。

PlantUMLで図を作りました。割と端折っているため、厳密な参考にはしないでいただきたいのですが、、、大体はこんなイメージです。
この図で説明すると、認証サーバの機能に関して、Keycloakが提供してくれてます。また、Webアプリに関しては基本的にはどのような言語やフレームワークでも実装可能ですが、OpenID Connectのクライアントとしての実装を行う必要があります。ちなみにアクセストークンはCookieに保存しても概ね問題ないようなのですが、アクセストークン自体にセキュアな情報を持たせないよう注意が必要となると思われます。

それでは実際にKeycloakをローカル上で試しに動かしてみます。
とてもありがたいことに、Keycloakは公式にDocker Imageが存在しているみたいなので、Dockerがインストール済みであれば下記コマンド一発で実行できます。

docker run -d -p 8080:8080  -e KEYCLOAK_USER=admin  -e KEYCLOAK_PASSWORD=password jboss/keycloak

コマンド実行したら、http://localhost:8080 にアクセスしましょう。

この画面がブラウザに表示されていれば、起動は完了です。
続いて、「Administrator Console」のメニューをクリックして、管理画面を開いてみます。

すると、管理者のログイン画面が開くと思います。
管理者のログイン名とパスワードですが、先ほどDockerコンテナ起動時のコマンドで環境変数として指定した

KEYCLOAK_USER=admin
KEYCLOAK_PASSWORD=password

がデフォルトで登録されているため、このアカウントで管理画面にログイン可能です。

ログインしたら管理画面が表示されます。

Keycloakの管理画面が開けることが確認できました。

管理画面のClientタブから、OpenID Connectでの連携を行うWebアプリの登録が可能になります。次回の記事では、デモ用のWebアプリの実行、そしてKeycloakのシングルサインオン機能を試しに行ってみたいと思います！お楽しみに！