1.
© Hitachi, Ltd. 2020. All rights reserved.
Keycloakの最近のトピック
OSSセキュリティ技術の会第8回勉強会 【オンライン】
2020/06/05
日立製作所 ＯＳＳソリューションセンタ
中村 雄一
田畑 義之

2.
© Hitachi, Ltd. 2020. All rights reserved.
Contents
1
1. Keycloakの最近の開発状況
- リリース状況
- 機能追加（OIDCのMetadata, WebAuthn）
- ＡＰＩ向け
- Cloud Native系 他
2. 非機能検証
- 検証内容
- 検証結果

3.
2© Hitachi, Ltd. 2020. All rights reserved.
最近のKeycloakリリース状況
時期 バージョン 主なトピック
2018/12/17 4.8.0 商用版Red Hat SSO 7.3のベース
（バグfix後の4.8.3が商用版のベース)
2019/01/15 4.8.3
2019/03/06 5.0.0 WildFly 15 (12/13)
2019/04/17 6.0.0 WildFly 16 (2/27)
Metrics強化
2019/08/24 7.0.0 WildFly 17 (6/10)
ＩＤトークン暗号化対応
アカウントコンソール刷新
2019/11/15 8.0.0 WildFly 18 (10/13)
WebAuthn対応
Vault
2020/02/17 9.0.0 商用版Red Hat SSO 7.4のベース
(バグfix後の9.0.3が商用版のベース)
2020/04/14 9.0.3
2020/04/29 10.0.0 WildFly 19対応
Token revocation endpoint(RFC7009)対応
商用版Red Hat SSOおよび
ベースのＡＰサーバ(WildFly)に合わせてvupしている

4.
3© Hitachi, Ltd. 2020. All rights reserved.
Server Metadataから見る強化(OpenID Connectのサーバとして）
OpenID Connectで定められた.well-known url(.well-known/openid-configuration)
から取得できる、OIDCのサーバとしての機能のアナウンス。
→ Keycloakは正直に申告しているので、機能の充実ぶりを観測することができる！
こんな感じで返ってきます
{
"issuer":"http://localhost:8080/auth/realms/master",
"authorization_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/auth",
"token_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/token",
"token_introspection_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/token/introspect",
"userinfo_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/userinfo",
"end_session_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/logout",
"jwks_uri":"http://localhost:8080/auth/realms/master/protocol/openid-connect/certs",
"check_session_iframe":"http://localhost:8080/auth/realms/master/protocol/openid-connect/login-status-iframe.html",
"grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials"],
"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code
id_token token"],
"subject_types_supported":["public","pairwise"],
"id_token_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES51
2","PS256","PS512","RS512"],
"id_token_encryption_alg_values_supported":["RSA-OAEP","RSA1_5"],
"id_token_encryption_enc_values_supported":["A128GCM","A128CBC-HS256"],
… "

5.
4© Hitachi, Ltd. 2020. All rights reserved.
Server Metadata強化： 4.8.3→9.0.0
・Claim数： 27→29
IDトークン暗号化サポートにより、“id_token_encryption_alg_values_supported”、
“id_token_encryption_enc_values_supported“が追加。
・Claim内の値の追加9件
各種署名アルゴリズムがRS256決め打ちだったのが、
RS384,RS512,ES256,ES384,ES512, PS256, PS384, PS512
にも対応したところがほとんど

6.
5© Hitachi, Ltd. 2020. All rights reserved.
主な新機能： WebAuthn
・ 11月リリースのKeycloak 8.0.0からExperimentalながらも対応！
- 日本コミュニティによる大きな成果
- 第5回で登場のwebauthn4j by @ynojima を利用
- 乗松さんがKeycloak用AuthenticatorをＰＲ、マージ
https://www.keycloak.org/docs/latest/server_admin/index.html#authentication

7.
6© Hitachi, Ltd. 2020. All rights reserved.
主な新機能： Vault
https://www.keycloak.org/docs/latest/server_admin/#_vault-administration
・ Keycloak内で取り扱われる機微な情報を確実に消すための仕組み
（例：SMTP接続のパスワード）
たとえファイルやＤＢで暗号化されて保存されていても、Keycloakに読みだされると、
ＲＡＭ上は平文で残ってしまうため。
・ Vault
Keycloak6.0.0から入った、機微データを取り扱う際、使用を終えたら確実に消す仕組み。
データを明示的に乱数で上書きするなどして消去されるようになる。
Vaultの枠組みに従ってプログラミングが必要。一部のデータのみがvaultで保護。
・ Vault SPIもある

8.
7© Hitachi, Ltd. 2020. All rights reserved.
増えているユースケース： ＡＰＩ向けのユースケース： 背景
・ REST APIの認証認可の標準として「OAuth2.0」が当たり前に
OAuthは「フレームワーク」。
認可サーバとしてしっかりした実装を使わないと穴ができる
・ KeycloakはOAuth2.0の認可サーバを備えるため、
REST APIの認証認可サーバとしても注目

9.
8© Hitachi, Ltd. 2020. All rights reserved.
ＡＰＩ向けのユースケース： よくあるKeycloakの使われ方
APIゲートウェイ
3scaleやNGINX
認可/認証サーバー
Keycloak
流量制御
認証認可
ディレクトリサービス
(LDAP, AD)
API利用者
API公開側
API
Server
API
Server
アクセス制御
外部IdPサービス
(Google,Github)
ユーザー情報DB
(任意のDB)
API管理基盤
①認証：OAuth2.0の中で認証・
アクセストークン発行・管理
②APIコール時のチェック
正しいアクセストークンが
あるリクエストのみ通す
アクセス
トークン
アクセス
トークン
RFC7662
Token Introspection

10.
9© Hitachi, Ltd. 2020. All rights reserved.
入門記事： Keycloakで実現するAPIセキュリティ@ThinkIT
ＡＰＩ認可サーバ用途に特化した入門記事連載をThinkITさんにて開始しました。
第一回(5/28公開）は基本的な概念の紹介。セッションとトークンの関係等、構築に必要な概念説明してます。
https://thinkit.co.jp/article/17559
第二回(6月終わりごろ予定）以降で、Keycloakコミッタでもある田畑さんから、具体的な構築方法を紹介します。

11.
10© Hitachi, Ltd. 2020. All rights reserved.
API向けに開発が進んでいる機能 (1/3) Client Policy
・ Client policyが入ったらFAPI用のprofileを実装予定
・ 並行して乗松さん・@wadahiro中心にFAPI Certification通すための課題洗い出し＆対処中。
https://github.com/jsoss-sig/keycloak-fapi
実装のPR議論中
https://github.com/keycloak/keycloak/pull/7104
https://github.com/keycloak/keycloak-community/blob/master/design/client-policies.md
・ 背景： 認可サーバとしてKeycloakの用途の多様化
- お試し用、OAuth2.0だけ、OIDCでのSSO、高セキュリティ用
- 各種規格もどんどん出てきている FAPI 1.0, FAPI 2.0, OAuth 2.1
⇒ Keycloakの「デフォルト設定」をどうするか悩ましくなってきた。
デフォルト設定を硬く(FAPI2.0等）にすると、他の人が使えなくなる
・ 開発状況
Client policyの設計ドキュメント： 承認済
・ Client Policy：
クライアント毎に用途に応じた設定・振舞いを「プロファイル」という形にできるようにしたもの by 乗松さん
・ Client policy自体はフレームワーク。
用途に応じてフレームワークに沿ってプロファイルを実装（例：FAPI 2.0用プロファイル）。
クライアントとプロファイルを対応付けることで、クライアント毎にプロファイルに対応した振る舞いをするようになる。
・ FAPI Certification

12.
11© Hitachi, Ltd. 2020. All rights reserved.
API向けに開発が進んでいる機能 (2/3) Decoupled flowへの対応
・ CIBA対応
OpenID Foundationで策定されたCIBAへの対応の開発開始。乗松さんが開発中。
https://github.com/keycloak/keycloak-community/pull/105
・ Device Authorization grant（和田さん元ネタ作成）も進行中。
https://github.com/keycloak/keycloak/pull/6992
サービス事業者
外部
アプリ
API公開する
機能・サービス
A
P
I
認可
サーバー
トークン
③トークン
②ユーザ認証
①連携リクエスト
サービス事業者
外部
アプリ
API公開する
機能・サービス
A
P
I
認可
サーバー
トークン
③トークン
②ユーザ認証
①連携リクエスト
認証用端末
認証用アプリ
Web
ブラウザ Web
ブラウザ
従来のOAuth2.0によるAPI連携 CIBAによるAPI連携
全ての処理をブラウザで行う
必要があり認証作りこみに限界
認証をブラウザから分離し
利便性の高い認証を実現

13.
12© Hitachi, Ltd. 2020. All rights reserved.
API向けに開発が進んでいる機能 (3/3) セッション周りの改善
・ リフレッシュトークンの有効期限の細かい設定： by田畑さん
レルムが同じだと、全てのクライアントに対してリフレッシュトークンの有効期限が同じ
→ クライアント単位で有効期限の設定機能を追加するＰＲマージ
(リフレッシュトークン/オフライントークン双方）
v11.0で対応予定。
・ RFC7009(OAuth 2.0 Token Revocation) ：10.0から
- これまでのリフレッシュトークン失効： logoutエンドポイント
独自仕様かつ複数クライアントへトークン発行されている場合、
全部失効されてしまう欠点があった。
- 10.0にて田畑さんがRFC7009対応。クライアント毎にリフレッシュトークン失効できるように。
アクセストークン単位では失効できないことに注意（あまり必要ないとは思いますが）
- メタデータ(well-known)に表示されるよう修正中

14.
13© Hitachi, Ltd. 2020. All rights reserved.
クラウドネィティブ系を意識した開発
・ Keycloak.X
・ Keycloak Operator
https://www.keycloak.org/2019/10/keycloak-x.html
・ 10月にブログで予告。Quarkusでの配布、無停止更新等々をめざす実験的なプロ
ジェクトとのこと。
・ Quarkusへの対応は少しづつ進んでいる模様
・ k8s上のOperator。Repoができてかなり活発に開発が進んでいる。
https://github.com/keycloak/keycloak-operator
・ CNCFへの提案
https://github.com/cncf/toc/pull/405

15.
14© Hitachi, Ltd. 2020. All rights reserved.
Gatekeeperについて
・ Gatekeeper : OAuth2/OIDCのProxy
・ GatekeeperがKeycloakから独立、louketo-proxyになった
https://github.com/louketo/louketo-proxy
現状、Keycloakチームと人員はほぼ共通。
・独立までの議論
https://groups.google.com/forum/#!msg/keycloak-dev/oDyw94BWxM0/zc0J9R10BwAJ
- CNCF入りをめざす(遠い将来)
- 同じRed Hat社員が率いる類似プロジェクトである、oauth2-proxyとのコラボも予定らしい。

16.
15© Hitachi, Ltd. 2020. All rights reserved.
非機能面
・ 性能面一般の話題は乏しい
⇒ 田畑の代理で中村がトピック紹介
・ コミュニティでの話題
- 無停止アップデート
現状、Keycloakをvupする際は、クラスタ全台止めてvupする必要がある。
- テストコードのＰＲから開始。
https://github.com/keycloak/keycloak/pull/7056
-バグ・脆弱性fixのvupからではと推測
- オフラインセッションロード時間
オフラインセッションが10万・100万単位になると、再起動時に数十分単位
で時間がかかることがある。
⇒チューニング方法がMLで議論
https://groups.google.com/forum/#!topic/keycloak-dev/NMeG3yKOIDo

17.
16© Hitachi, Ltd. 2020. All rights reserved.
Keycloakの非機能検証をするに至った背景
• APIの需要が高まり、Keycloakの適用されるシステムが扱うユーザ数も、数
万、数十万、数百万と大きくなってきている。
<見積もり時の課題>
• 「ユーザ数が〇〇万人の場合のKeycloakのマシンスペック」が見積もれ
ない。
• なぜなら、サイジングガイドラインがないから。。。
• 公式情報でも「ない」
https://access.redhat.com/solutions/3217681
→非機能検証しましょう。

18.
17© Hitachi, Ltd. 2020. All rights reserved.
非機能検証の内容
• 観点は大きく以下の2つ。 ※あくまでAPI認可サーバとしてのシナリオ
1. ユーザ数観点での検証
• Keycloakでは、ログインセッションをメモリ上で管理している。
• ではログインユーザ数が、1万, 10万, 100万と増えていったときに、メモリ
はどのくらい必要になるのか。
2. スループット観点での検証
• Keycloakには、トークンの有効性を検証するために、トークンイントロスペ
クションという機能がある。この機能は、クライアントからAPIが呼ばれるた
びに、リソースサーバやAPIゲートウェイから利用されるため、APIのスルー
プットに影響を与える。
• ではトークンイントロスペクション自体はどのくらいのスループットが出るの
か。
• 検証に使用したバージョンは4.8.3.Final。

19.
18© Hitachi, Ltd. 2020. All rights reserved.
• メモリ総使用量
• (*) オフライントークンとは、DBにトークンを永続化する仕組み。オフライントークンを使用すると、メモリ使用
量が増える。
• ベースとなる使用量を除くと、ログインユーザ数に比例してメモリ使用
量が増加していることがわかる。
• システム要件にある「At least 512M of RAM」だと、10万ユーザは厳
しいかもしれない。
検証結果① ユーザ数観点での検証
1万ユーザ 5万ユーザ 10万ユーザ
オフライントークン(*)なし 120M 210M 320M
オフライントークン(*)あり 140M 300M 510M

20.
19© Hitachi, Ltd. 2020. All rights reserved.
検証結果② スループット観点での検証
• 必要コア数 (ログインユーザ数は10万固定)
• (*) トークンイントロスペクションのみのスループット。
• トークンイントロスペクションのみだと、さほどCPUを消費しない。
• メモリ使用量も検証したが、スループットへの影響は微小。
ただし、少なすぎるとGCが走ってしまい、スループットは落ちる。
1000 RPS(*) 2000 RPS(*) 2500 RPS(*)
必要コア数 1コア 2コア 3コア

21.
20© Hitachi, Ltd. 2020. All rights reserved.
まとめ
• ユーザ数とスループットから想定される必要マシンスペック
(トークンイントロスペクションが大量に発生する場合)
あくまで一例！
• より大規模な非機能検証も実施中。
1000 RPS 2000 RPS 2500 RPS
~10万ユーザ CPU: 1コア
メモリ: 1GB
CPU: 2コア
メモリ: 2GB
CPU: 3コア
メモリ: 2GB

22.
21© Hitachi, Ltd. 2020. All rights reserved.
他社商品名、商標等の引用に関する表示
・Kubernetesは、The Linux Foundationの米国およびその他の国における登録商標または商標です。
・Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
・Red Hat and OpenShift are registered trademarks of Red Hat, Inc. in the United States and other
countries.
・NGINXは、NGINX,Inc.の登録商標です。
その他記載の会社名､製品名は､それぞれの会社の商標もしくは登録商標です｡