Keycloakの最前線を体感できるイベント「Keyconf 23」レポート

2023年8月18日(金)
乗松 隆志中村 雄一
IAM用OSSのKeycloakに関するイベントKeyconf 23が、2023年6月16日に開催されました。キーノートをはじめとするイベントの内容を紹介します。

Keyconfとは

Keyconfとは、CNCF Incubating Projectとして注目される認証や認可を担うOSSであるKeycloakに関する国際会議です。Keyconfの特徴としては、小規模ながら、Keycloakの開発者やヘビーユーザーが集まり、ディープな議論が行われるところです。

今回のKeyconf 23(公式からのアナウンス)は、2019年以来2回目の開催です。Keycloakの認証や認可のプロトコル対応の開発を推進するグループであるOAuth SIGの中で開催の準備が行われ、筆者も会議の企画段階から参画しました。本SIGのメンバーでもあるBanfico社とAdorsys社が主催として会場を提供してくれることとなり、2023年6月16日にイギリス ロンドンのOne Canada Squareビル39階にあるLevel 39にて開催されました。

Keyconf 23では、Keycloakプロジェクトの状況、ユースケース、開発予定に関して8件の発表が行われました。参加者は30~40人ほどであり、Keycloakのメンテナは筆者を含めて3名参加し、活発な議論が行われました。以降にセッションの状況を報告します。

Keycloakの歴史とプロジェクトの状況

本カンファレンスのKeynoteでは、Red Hat社に所属するKeycloakのメンテナであるMarek Posolda氏から、Keycloakの概要とこれまでの歴史と開発状況が紹介されました(図1)。Marek氏は、最初期の2013年よりKeycloakの開発に携わり、Keycloakのメンテナの中でも、Keycloak本体のコードのcommit数は現在第2位と活発に活動されています。

図1:Marek Posolda氏

図1:Marek Posolda氏

はじめに、Keycloakの機能が改めて紹介されました。KeycloakはIAM(Identity and Access Management)用OSSであり、Out-of-Boxで、アプリケーションやRESTサービスを安全に、手間をかけずに使えるようにするものです。Webベースのアプリに対しては、シングルサインオン(SSO)を提供しています。またKeycloakは、主要な認証及び認可プロトコル(OAuth 2.0、OpenID Connect(OIDC)、Security Assertion Markup Language(SAML))に対応しており、ユーザーフェデレーション、強力な認証方式、ユーザー管理、きめ細かい認可、ソーシャルブローカリングなどを提供しています。

次いで、Keycloakの歴史と開発状況が紹介されました。Keycloakは、2013年にBill Burke氏とStian Thorgersen氏により開発が始められました。現在は、Stian氏がKeycloakのProject Leadです。最初のリリースは2014年であり、会議時点の最新のリリースは、Keycloak 21.1.1です。Keycloakのコミュニティについては、コントリビューターの数は894、GitHubレポジトリのstarの数は16400、フォークの数は5500、コミットの数は22142と活況を呈しています。

Keycloakは標準仕様に準拠しており、特にOpenID FoundationのOpenID Connect(OIDC)に関しては、主要な項目について認定を取得しています。また、FAPI(Financial Grade API、参考記事)の認定もKeycloak 15から取得しており、FAPIをベースとした各国のOpen BankingのセキュリティプロファイルであるBrazil Open BankingやAustralia CDRの認定も取得しています。これらの認定取得に関して、筆者が携わっているOAuth SIGに対して謝辞がありました。そして、Keycloakは2023年4月にCNCFのIncubation Project入りを果たし、多くの企業や団体での利用実績があることが触れられました。

Keynoteに続いてMarek氏より「Keycloak - recently added features」という題名で、ここ1、2年で追加された機能の紹介がありました。概ね「CNCFプロジェクトとKeycloakの動向」で紹介したものでしたが、それ以外で特筆すべき点として、FIPS 140-2のサポートが挙げられます。FIPS 140-2は米国政府が定める暗号モジュールの規格であり、米国政府だけではなく、グローバルの公共関係や金融機関でも採用される規格です。FIPS 140-2準拠のモードでKeycloakを走らせることができるようになっています。

先述のFAPIもそうですが、Keycloakは公共関係や金融機関などで求められる高いセキュリティ要件を満たすことができるようになっており、後続のセッションでも金融分野や公共分野の事例が紹介されています。KeycloakはOSSでありながらも、重要なシステムの一角を担えるほどまでに成長していると実感しました。

OpenBankingとKeycloakの関係

Marek氏のセッションでも紹介があったようにKeycloakはFAPIやFIPSなど金融機関向けを意識した機能が充実しています。今回のKeyConfでも銀行向けの事例の紹介が2件ありました。

会場のLevel39にオフィスを構えるBanfico社のCEOのKannan Rasappan氏およびAdorsys社のCTOのFrancis Pouatcha氏からは「KEYCLOAK - OPEN BANKING」と題して、Open BankingとKeycloakの関係について説明がありました(図2)。

図2:Kannan Rasappan氏(右)、Francis Pouatcha氏(左)

図2:Kannan Rasappan氏(右)、Francis Pouatcha氏(左)

Banfico社は、Keycloakを利用してOpen Banking用のサービス基盤をイギリス、ブラジル、サウジアラビアなど世界各国で提供しています。Open Bankingとは、銀行の持つ顧客のデータをFintech企業などの第三者とAPIを通じて連携することで新たな価値を創出しようという取り組みであり、世界各国で推進されています。

Open Bankingを実現するための構成要素として、OIDCやFAPI、Client Initiated Backchannel Authentication(CIBA)準拠の認可サーバー、他のIdP(アイデンティティ・プロバイダ)との統合、APIゲートウェイ、エンドユーザーからの同意の管理、強力な認証機構、規制当局からの監査というものがあります。Keycloakはその中でOpen Bankingでの認可サーバーとして利用できる、最もポピュラーなOSSであるとの言及がありました。その理由としては、FAPIといった標準仕様に準拠していたことが挙げられました。

銀行向けプラットフォームへの適用事例

銀行向けのより具体的な事例として、Backbase社のDmitry Telegin氏より「Keycloak at the core of the Engagement Banking Platform」と題した講演が行われました(図3)。

図3:Dmitry Telegin氏

図3:Dmitry Telegin氏

Backbase社はオランダ・アムステルダムに本拠地を置き、Keycloakを利用した銀行サービスプラットフォームを提供しています。Dmitry氏はKeycloakに多数のパッチ投稿をしている方でもあります。Backbase社は、The Engagement Banking Platformと銘打ち、Kubernetesをベースとした銀行サービスプラットフォームを提供しており、KeycloakがIAM用途として利用されています。このプラットフォームは150を超える銀行や金融機関に利用されており、各金融機関のエンドユーザー数としては2万人から多いものでは2千万人にもなるとのことでした。

ここで、各顧客によりさまざまな要望が出てくるため、Keycloakにもそれに応じてカスタマイズを行っています。例として、複数の経路によるOTP認証やデバイスの認証等独自の認証の作りこみや、パスワード忘れのリンクのためのエンドポイントの実装などが挙げられました。

時にはKeycloakのソースに手を入れてカスタマイズを行っているため、Keycloakのバージョンアップに追随することが大変であることへの言及がありました。バージョンアップに追随しやすくするために、適宜Keycloakにコントリビューションしているとのことでした。まさにKeycloakがOSSかつコミュニティが活発であるからこそ、このようなことができていると感じました。

グローバル企業の社内認証基盤の事例

ここまでは、金融向けの事例でしたが、企業内部での認証基盤として使われている事例の紹介もありました。Bosch社のSebastian Schuster氏から、「KEYCLOAK@BOSCH」と題して、グローバル拠点間で大規模な認証基盤としてKeycloakが使われている事例が語られました(図4)。

図4:Sebastian Schuster氏

図4:Sebastian Schuster氏

Sebastian氏は、2023年2月からKeycloakのメンテナに就任したドイツBosch社所属の方です。Sebastian氏が所属するBosch社は各国の拠点を結んだネットワークでの認証基盤にKeycloakを利用しており、これについての説明がありました。

Boschでは、Keycloakをas a Serviceとして社内の認証基盤として提供しているとのことで、世界3拠点を対象とし、一ヶ月あたりのリクエスト数は35億、一ヶ月あたりのアクティブユーザー数は50万にもなる大規模なものです。Keycloak as a Serviceの基盤としてはAzureを使っており、インスタンス数は70もあり、10人ほどのスタッフ(半数が開発、もう半数がDevOps)で開発・運営されています。さらには、KeycloakのSPIを利用したカスタマイズによる拡張は1000を超えており、バージョンアップのたびに動作確認や動かない場合の対応を行っているそうです。

インフラとしては、Azureのサービスを活用しており、Traffic Manager、Application Gateway、Azure Kubernetes Service、Azure SQL、Azure Service Busなどを用い、グローバル拠点間のレプリケーションの実現など、大規模な運用を可能としているとのことでした。

筆者としては、このような大規模なシステムでもKeycloakが使えるということ、またそういったシステムを支えている方がKeycloakのメンテナに加入して下さったことに、心強さを感じました。

公共分野での適用事例

ギリシャの学術機関にネットワークサービスを提供するギリシャ政府機関GRNETに所属のNicolas Liampotis氏より、「Check-in Authentication & Authorization with Keycloak」と題して、公的機関へのKeycloakの事例が紹介されました。

EU議会により資金が拠出され設立されたEuropean Grid Infrastructure(EGI)における、The EGI Check-in serviceという認証サービスにKeycloakが利用されています。800もの外部認証プロバイダ(Google、Facebook等)に対応したシングルサインオンを実現することができるということです。

Keycloakを採用した理由としては、外部認証プロバイダに認証を委ねる機能(Identity Brokering)に対応している、標準仕様への対応が十分である、強力な多要素認証機能、スケーラビリティの他、コミュニティが活発であることが挙げられました。

標準仕様の準拠が充実している例としては、OAuch.ioという、標準仕様への準拠具合やセキュリティのベストプラクティスの適用具合をテストするサイトを用いて、Keycloakを適用したEGI-Checkinをテストしてみたところ、テストにパスしなかった割合は4.2%だったそうです。これは他の実装に比べて低いものであり、例えば、MITREidを適用した場合のパスしなかった割合は20.4%だったとのことです。

そのほか、独自にKeycloakへの拡張を施しているということでしたが、筆者の立場としてはコントリビューションするように促していきたいと思いました。

筆者からはFAPIや関連する機能の開発状況を発表

筆者からは、「Securing APIs in Open Banking - Financial-grade API security profile implementation to Keycloak」と題して、高いセキュリティレベルが要求されるAPIに対するセキュリティ仕様である Financial-grade API(FAPI)Security Profileとその普及状況、そしてFAPIのKeycloakへのサポートについての取り組みについてデモを交えて紹介しました(図5)。

筆者(乗松)によるプレゼンのようす

図5:筆者(乗松)によるプレゼンのようす

また、今後Keycloakにサポートしていきたいと考えている次のような機能を紹介しました。

  • FAPI 2.0:Keycloakがサポート済のFAPI 1.0の次バーション。採用を決めているOpen Bankingの仕様が出てきている。記事執筆の時点で、必要な機能はマージされています(FAPI 2.0 security profile - supporting RFC 9207 OAuth 2.0 Authorization Server Issuer Identification(Pull Request))
  • OpenID Connect for Identity Assurance 1.0(OIDC4IDA):IDトークンやUserInfoレスポンスに含まれる認証済みユーザー情報に、その情報がどれだけ信用がおけるかRelying Party(RP)が判断できる情報を付与する。eKYC(オンラインによる本人確認)を重視するユースケースに有効です。記事執筆の時点で、PoC実装を筆者と同僚より提案中です(implement oidc4ida(Pull Request))
  • OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer(DPoP):これまでのKeycloakではコンフィデンシャルクライアントで送信者とアクセストークンを関連付けて検証することができましたが、本仕様に対応することでパブリッククライアントでも同様のことが実現できます。記事執筆現在、基本的な機能はマージされています(DPoP support(Issue))
  • Reference Token:Keycloakのアクセストークンには、さまざまな情報が含まれますが、ユースケースによっては情報を含まないほうが望ましいことがあります。そのような自身に情報を含まないアクセストークンをreference tokenと呼び、筆者を中心に提案中です(Supporting a reference/lightweight access token(Issue))。記事執筆の時点で、一部の機能がマージされています

これらの開発中の機能について、参加者より数多くのフィードバックをいただけて、その場に関係する開発者もいたため議論も大きく前進しました。GitHub上のやり取りだけでは行き詰っていた項目もありましたので、こういった議論がオフラインのカンファレンスの醍醐味であると感じました。

Keycloakの開発予定の共有

最後にMarek氏より「Keycloak - roadmap ideas」と題して、確定していないが今後サポートを考えている機能の紹介がありました。以下に共有された内容を列挙します。

  • Client Types:Service Accountに種別を設け、各種別で同じ設定およびその変更を自動的に行えるようにするもの。デフォルトでいくつかの種別を用意し、バージョニングのサポートも考えている
  • User Profile:ユーザー登録時などのフォーム画面で表示するユーザーのAttributeを定義するもの。あるAttributeはユーザーからの入力を受け付け、他のAttributeはユーザーからは参照のみにするといった、アクセス制御も実現する
  • Progressive Profiling:クライアントやユーザーの設定・Attributeについて、登録時にすべての入力を求めるのではなく、それが必要になったときに段階的に入力を求めるようにするもの
  • Multi Tenancy:同じクライアントやユーザーを異なるレルムに登録し運用することがある。例えば、あるユーザーが異なる組織に所属するなど。この場合、クライアントやユーザーの管理が重複するため、マルチテナントを実現したい。方法として、レルムの配下に複数の別の管理用エンティティ(Organization)を設けられるようにするとか、複数のレルムを含むことができる親レルムのようなものを設ける方法を考えている
  • Authentication Policy:ポリシーベースの方法で、認証フローを決められるようにする。例えば、@keycloak.orgというメールアドレスのドメインを持っているユーザーに対しては2要素認証を要求する等
  • Cross-datacenter replication:2018年にすでにKeycloakでサポートしているが、Technology Preview扱いである。これを正式サポートレベルに改良する。Keycloakではデータストアの再設計を行っているが、まずは旧データストアでの正式サポートを目指し、次いで新データストアでの正式サポートを目指す。だが、作業は遅れている

また、OAuth SIGでサポートを考えている機能として、筆者が先のセッションで紹介したFAPI 2.0、DPoP、ReferenceTokenが挙げられました。

おわりに

本イベントは、10時開始16時終了の予定でしたが、質疑が盛り上がり3時間オーバーとなり19時ごろの終了となりました。大幅に時間オーバーしたにも関わらず、参加者はほぼ最後まで残って議論に参加し、会場は終始熱気に包まれていました。議論の中で開発者間の交流が深まり、筆者としても今後のコントリビューションがやりやすくなったと感じました。また、当日使われた資料の一部についてはKeycloakのOAuth-SIGのGitHubレポジトリで公開されていますので、参照いただければと思います。

オフラインでのイベントにはオンラインには替えがたいメリットがあることを実感できましたので、日本国内およびグローバルでもオフラインのイベントを企画していきたいと考えていますので、ご期待いただければと思います。

日本国内については、OSSセキュリティ技術の会での開催を企画していく予定ですので、こちらのサイトより加入いただければイベント開催通知を受け取れます。また、グローバルについてはKeycloakのslackチャンネルよりキャッチアップできます。興味のある方はこちらから加入いただければと思います。

株式会社 日立製作所
OSSソリューションセンタにて、API管理や認証周りのOSSの開発に従事。keycloakコミュニティに多数のコードをコミットしている。2021年10月からkeycloakのメンテナーとして活動。
株式会社 日立製作所

SELinuxから始まりOSSコミュニティ活動を長年行っている。近年は、OSSソリューションセンタにおいて、Keycloakのアップストリーム活動と関連ビジネスを立上げるなど、OSS戦略を推進中。また、The Linux Foundationのボードとして、日本国内のOSSコントリビューションの盛り上げに挑戦中。

Cloud Native Community Japanの設立発起人、OSSセキュリティ技術の会会長。博士(工学)。

連載バックナンバー

OSイベント

RHEL互換LinuxのAlmaLinuxがセミナーを開催。サイバートラストのセッションを主に紹介

2024/3/28
RHEL互換LinuxのAlmaLinuxがセミナーを開催。サイバートラストのセッションを主に紹介する。
セキュリティイベント

FIDOが東京でセミナーを開催、パスキーについてデジタル庁の責任者が講演を実施

2024/3/19
FIDO Allianceが東京でセミナーを開催した。パスキーについてデジタル庁の責任者が実施した講演の内容を紹介する。
データベースSponsored

【事例から学ぶ】アーキテクチャ多様化時代にデータベースを「TiDBにまとめる」という選択

2024/2/9
実際にマイクロサービスアーキテクチャでありながらも、データベースをTiDBへまとめている合同会社DMM.com、Micoworks株式会社、menu株式会社が、なぜその判断に踏み切ったのか、そもそもどこに課題感があったのかなどを背景と共に紹介します。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています