2018/7/13 OSSセキュリティ技術の会勉強会の資料

1. © Hitachi, Ltd. 2018. All rights reserved.
2018/7/13
日立製作所 OSSソリューションセンタ
中村雄一
Keycloak最新動向
Red Hat Summit報告＆セキュリティ強化
OSSセキュリティ技術の会 第三回勉強会

2. © Hitachi, Ltd. 2018. All rights reserved.
なぜRed Hat Summit?
1
・ KeycloakのOSSコミュニティはRed Hat社により運営
（メンテナもRed Hat所属の方）
・ Red Hat社は商用サポート付きの
Keycloak「Red Hat Single Sign-on(Red Hat SSO)」を提供
・ Red Hat Summitに行くと、、、
- Red Hat SSOの最新動向がわかる（Keycloakのほうも想像つく）
- 主要開発者に会えるかも？
・ Red Hat Summit 2018/5/8-11 ＠サンフランシスコ にて開催
・ Red Hat SSOロードマップ
・ 事例
・ メンテナとのコミュニティ打ち合わせ
を報告します

3. © Hitachi, Ltd. 2018. All rights reserved.
Red Hat SSOロードマップ
2
セッションにてRed Hat SSOのロードマップが紹介
講演時点では7.2
(Keycloak 3.4系）が最新
2019年春ごろに向けて
色々な機能の開発が進んでいる
Istio連携
UMA2.0
WebAuthn

4. © Hitachi, Ltd. 2018. All rights reserved.
マイクロサービス系との連携強化
3
・ OpenShiftのデフォルトのOAuthサーバ(OSIN)の代わりに(並列して？）
Keycloakを使えるようになっていく模様
・ ホットになりそうなのがIstio連携
- Istio
- Kubernetes上のサービスメッシュ、最近急に注目されている
マイクロサービスの通信（認証含む）等を面倒見てくれる便利なもの
- OpenShiftに入っていく予定
- Istioのデフォルトの認証は、
Mutual TLS。
⇒これにKeycloakを対応させて
いく動き。
https://blog.keycloak.org/2018/02/keycloak-and-istio.html
・ コンセプトはこちら
https://issues.jboss.org/browse/KEYCLOAK-6205
・ ＪＩＲＡ

5. © Hitachi, Ltd. 2018. All rights reserved.
他注目トピック
4
１） ＵＭＡ２．０への対応
・ Authorization ServiceのインタフェースがUMA2.0に対応していく
(Keycloak 4.0.0で対応済）
- Authorization Service
誰が何にアクセスできるのかのポリシー管理とアクセス判断のエンジン
- UMA (User Managed Access) 2.0
Kantara Initiativeにて標準化が進むアクセス権管理の仕様。
https://issues.jboss.org/browse/KEYCLOAK-7159
３） Go言語のProxy
２） WebAuthn対応
・ 主要ブラウザが対応を表明したパスワードレス認証規格WebAuthnへRed Hat
SSOも対応していく方針表明。
・ Keycloak側ではまだ実装は進んでいない。
- JIRAを要ウォッチ
・ これまで、Proxy型のSSOをやりたい場合は他のＯＳＳと組み合わせ。
- Apacheのmod_auth_openidc （一般的なシングルサインオンの場合）
- 3scaleのapicast (API認可認証の場合）
・ Red Hat SSOとしてもproxy(Go言語ベース）を用意する方針とのこと。
- ＪＩＲＡ：
https://issues.jboss.org/browse/KEYCLOAK-6203

6. © Hitachi, Ltd. 2018. All rights reserved.
事例の紹介
5
Red Hat社のAPI管理基盤である3scaleとの連携事例を紹介。
スイス国営鉄道のAPI公開の認可認証をRed Hat SSOで実現。
3scaleのセッションでも、Red Hat SSO(Keycloak)連携事例の紹介あり

7. © Hitachi, Ltd. 2018. All rights reserved.
コミュニティmeeting
6
Red Hat Summit会場にて、
Keycloak主要メンバ(メンテナのStianさん、エバンジェリストのSebastienさん）と、
日本コミュニティの打ち合わせを開催
色々と意見交換
• Financial API (FAPI)向けの開発項目について
• FAPI、というよりOpenID Connect一般について興味ある感じ
• 優先度と必要性について意識を合わせ、githubベースで議論中
＃ 後ほど詳細
• OpenStandiaさんの日本語ドキュメントプロジェクト
• 大変好評で、後日Keycloakのページからリンクが貼られた
https://www.keycloak.org/extensions.html
Twitterを活用しているようで、つぶやくと反応してもらえるかも？

8. © Hitachi, Ltd. 2018. All rights reserved.
セキュリティ強化について
7
日立の乗松さん(@tnorimat)が、OpenID Foundationの
FAPI(Financial API)対応のためのパッチ開発してるので紹介します。

9. © Hitachi, Ltd. 2018. All rights reserved.
Financial API (FAPI)とは？
8
OAuth
OpenID
Connect
(OIDC)
「アクセストークン」をやり取りする認可の仕様。
自由度が高く、そのまま使うと
セキュリティホールを作り込んでしまう。
OAuthの使い方を縛り、かつ
「アクセストークン」の中に「ＩＤ情報」を
含めてやり取りできる仕様
⇒まだ自由度は高く、使い方によって
セキュリティレベルがバラバラ
OAuth/OIDCの安全な使い方を規定。
オプション仕様の使い方、下のレイヤ
(SSL/TLS)の使い方等。
APIの形式などは規定されていない。
ＦＡＰＩ
・金融ＡＰＩ公開にあたっての OAuth/OIDCの安全な使い方の規定。
OpenID Foundationで策定が進む
Part1(ReadOnly、照会系API向け), Part2(ReadWrite,更新系API向け）
が、現在Implementer’s draft
APIセキュリティのベストプラクティスを取り込んだものになっているため、
金融以外にも役立つと思われる。⇒ Keycloakでも対応してみよう！

10. © Hitachi, Ltd. 2018. All rights reserved.
KeycloakとFAPI仕様のFIT&Gap
9
• 標準モノは、標準化団体のcertification testを通すのが本来。
• しかし、FAPI自体がまだ途中＆testも未完成。
• 「認可サーバとして」のKeycloakを評価。2017年3末時点(Keycloak
3.0.0)に、FAPIの仕様書と関連する仕様を読み込んで、非対応部
分を洗い出しました
• 動作確認＆ソースもがっつり読み込み。細かいところも作りこま
れている印象でしたが、ＦＡＰＩは意識していなかった

11. © Hitachi, Ltd. 2018. All rights reserved.
Keycloak 3.0.0 (2017/3リリース）でのFAPI非対応部分
10
非対応部分を洗い出してJIRAに報告。
一つ一つパッチを実装開始！
https://issues.jboss.org/browse/KEYCLOAK-6767
JIRA 課題概要
KEYCLOAK-2604 RFC 7636(PKCE)対応
KEYCLOAK-5661 shall return the list of allowed scopes with
the issued access token
KEYCLOAK-5811 client_secret_jwtでのクライアント認証
KEYCLOAK-6700 s_hashのサポート
KEYCLOAK-6769 多要素認証には対応しているが、IDトークン
のacrセットされていない
KEYCLOAK-6768 ＩＤトークン暗号化
KEYCLOAK-6770 PS256またはES256での署名対応
KEYCLOAK-6771 Holder of Keyへの対応
非対応項目のまとめＪＩＲＡ：
各項目：

12. © Hitachi, Ltd. 2018. All rights reserved.
2018/6末 時点の開発状況
11
JIRA 課題概要 @tnorimatの
Pull Request
対応バージョン
KEYCLOAK-2604 RFC 7636(PKCE)対応 3831 3.1.0
KEYCLOAK-5661 shall return the list of allowed scopes with
the issued access token
4527 3.4.0
KEYCLOAK-5811 client_secret_jwtでのクライアント認証 4835 4.0.0
KEYCLOAK-6700 s_hashのサポート 5022 4.0.0
KEYCLOAK-6769 多要素認証には対応しているが、IDトークン
のacrセットされていない
まだ まだ
KEYCLOAK-6768 ＩＤトークン暗号化 まだ まだ
KEYCLOAK-6770 PS256またはES256での署名対応 議論中 まだ
KEYCLOAK-6771 Holder of Keyへの対応 5083 4.0.0
だいぶ整備されました。

13. © Hitachi, Ltd. 2018. All rights reserved.
トピック： ＰＫＣＥ対応
12
・ RFC7636”Proof Key for Code Exchange by OAuth Public Clients” 略して「PKCE」
・ OAuthのAuthorization code grantで最初に発行される認可コードの横取り・置換攻撃
を防ぐための仕様（フローの中でパラメタ追加）
・ Public client(スマホアプリ等）を想定して作られた仕様だが、最近では全てのclientで
の有用性も指摘されている。
OAuth 2.0 Security Best Current Practice(Mar 18,2018)より引用
https://tools.ietf.org/id/draft-ietf-oauth-security-topics-05.html
Note: although PKCE so far was recommended as mechanism to protect native
apps, this advice applies to all kinds of OAuth clients, including web applications.
Keycloakでは...
・ PR3831(@tnorimat)により、認可サーバ側が対応(3.1.0から）。
解説記事： https://qiita.com/tnorimat/items/e2dd3ecd36f192fca5ba
・ ＦＡＰＩの認可サーバ側では、PKCE対応がshall。
PKCEとは
・ クライアントアダプタ側の対応も進んでいる。Java scriptクライアントアダプタ
でのPKCE対応：PR5255(@thomasdarimont)、現在レビュー待状態。

14. © Hitachi, Ltd. 2018. All rights reserved.
Holder of Key mechanismとは？
13
背景： ベアラトークン
・ OAuth/OIDCのトークン類（アクセストークン・リフレッシュトークン）は、
基本「トークンを持っている人を信じる」という考え方(ベアラトークン）
⇒ トークンを盗んだら誰でも使えてしまう。
Holder of Key
・ 「トークンを本来持っている人」しかトークンを使えなくする技術。
- トークンの所持者を証明する属性（秘密鍵）とトークン関連付け
- APIサーバ側では、本来の所持者から来たトークンであるかを検証する。
・ 2通りの標準 (双方IETFのドラフト段階）
１）[MTLS] : OAuth 2.0 Mutual TLS Client Authentication and Certificate
Bound Access Tokens
〇： 広く使われた技術がベース
×： クライアント証明書が必須
２）[OAUTB]：OAuth 2.0 Token Binding
〇： 認可コードまでも所持者証明可能で、クライアント証明書不要
×： 参加者全てにTLSレイヤの拡張が必要
FAPIでは、[MTLS]もしくは[OAUTB]どちらか実装。

15. © Hitachi, Ltd. 2018. All rights reserved.
Holder of Key mechanismのKeycloakでの実装
14
・ [MTLS]を実装。[OAUTB]は断念（TLS拡張された有名ライブラリが見当たらないため）
https://github.com/keycloak/keycloak/pull/5083/
にて提出、マージ。
実際にトークンが盗まれたケースを想定したテスト付
Keycloak 4.0.0のリリースノートでも大きく取り上げられました。
「OAuth2 Certificate Bound Access Tokens」という名称になりました。
https://www.keycloak.org/docs/4.0/release_notes/index.htmlより引用

16. © Hitachi, Ltd. 2018. All rights reserved.
署名アルゴリズム
15
課題
・ OAuth/OIDCでは、トークン類に署名している。Keycloakでは署名
アルゴリズムとしてRS256を利用。
⇒ RS256は安全性が高くないと言われており、FAPIではES256 or
PS256が必須。
実装
・ 結構大変。至る所にRS256がハードコード！
・ ＭＬなどで議論、なんでも差し込めるように、メンテナに助けてもらって、
リファクタリング中。近い将来入れるよう進めて頂いている
・ MLの議論スレッド
http://lists.jboss.org/pipermail/keycloak-dev/2018-May/010858.html
http://lists.jboss.org/pipermail/keycloak-dev/2018-June/010959.html
・ Pull Requests
リファクタリング
https://github.com/keycloak/keycloak/pull/5309
https://github.com/keycloak/keycloak/pull/5260
ES256対応サンプル
https://github.com/keycloak/keycloak/pull/5225

17. © Hitachi, Ltd. 2018. All rights reserved.
残項目
16
・KEYCLOAK-6769： WebAuthn対応の開発が始まったら入れ込みたい
・KEYCLOAK-6768： 雛形はあるため、そんなに時間がかからないと想像。他が片付いたら。
FAPIの公式テストについて
最終的にはＣｅｒｔｉｆｉｃａｔｉｏｎ用のテストを通す必要があるが、まだない。
それっぽいものがあるので、要ウォッチ。
https://gitlab.com/fintechlabs/fapi-conformance-suite

18. © Hitachi, Ltd. 2018. All rights reserved.
感想
17
・ 製品のベースになってるから、クローズなコミュニティなのかな？
と思っていたが。。。
・ 全く部外者でも、パッチを出しているうちに反応がよくなってきた。
気に入らないところがあれば、どんどんパッチ書いてもよい模様
- 最近もOffline Token(Keycloak用語,scope=offline_accessのリフレッシュトークン）の
有効期限の考え方が気に入らなかったのでパッチ出したらすぐ入りました。
KEYCLOAK-7688 Offline Session Max for Offline Token:
https://github.com/keycloak/keycloak/pull/5307
・ 日本からもどんどんパッチを出して、良いＯＳＳにしていきましょう！

19. © Hitachi, Ltd. 2018. All rights reserved.
おまけ
18
Keycloakとその応用の3scale(API管理）について、
Qiitaに記事公開開始しました。
・第一弾公開: 3scale 2.2を使ってみた
https://qiita.com/yo-tabata/items/eb81c5cb324cefa87efc
（Qiitaを”3scale”で検索したらすぐ出てきます）
Keycloakを包含するAPI基盤
3scaleの新バージョン2.2と開発動向の紹介です。
Keycloak関連記事なども準備中。

20. 19© Hitachi, Ltd. 2018. All rights reserved.
他社所有商標に関する表示
• HITACHIは、株式会社 日立製作所の商標または登録商標です。
• Red Hatは米国およびその他の国におけるRed Hat, Inc.の登録商標です。
• Kubernetesは米国およびその他の国におけるThe Linux Foundationの登録商標です。
• OpenShiftは米国およびその他の国におけるRed Hat, Inc.の登録商標です。
• その他記載の会社名、製品名などは、それぞれの会社の商標もしくは登録商標です。