RHBK学習メモ

目的

RH-SSOからRHBKへ移行するプロジェクトを成功に導くため、RHBKの基本的な知識&スキルを習得する。

目標

以下を説明できるようになり、RHBKの基本操作（スターティングガイド）もできる状態にする。

• RHBKとはなにか？
• RHBKによる認証の仕組み
• RHSSOとRHBKの差分
• RHBKの基本操作

インプット

• RedHat 公式ガイド
• RedHat スタートガイド
• 赤帽エンジニアブログ Red Hat SSO改めRed Hat build of Keycloakの変更点やマイグレーション情報について
• NRIサイト
• 日立 Keycloakとは？
• 赤帽エンジニアブログ PodmanではじめるRed Hatのミドルウェア製品：Keycloak

📌 Zennでのアウトプットアイデア

1️⃣ RHBK入門シリーズ（概念編）

🔹 記事タイトル例
👉「RHBKとは？RH-SSOからの移行を成功させるための基礎知識」

🔹 内容

• RHBKとは何か？（Keycloakとの関係、OSSの成り立ち）
• RHBKのアーキテクチャ（認証の仕組み、OIDC/SAML対応）
• RH-SSOとの違い（機能面・運用面での比較）

📌 目的：まずRHBKが何かを初心者にも分かりやすく解説する

2️⃣ RHBKスタートガイド（操作編）

🔹 記事タイトル例
👉「RHBKの基本操作まとめ！インストールから認証設定まで」

🔹 内容

• RHBKのインストール手順（公式ドキュメントに沿って実施）
• 管理画面の基本操作（Realmの作成、クライアント登録）
• ユーザー管理と認証設定（ユーザー追加、ロール設定）

📌 目的：公式ドキュメントを自分の言葉で整理し、実際に試すことで理解を深める

3️⃣ RHBKで認証を試してみた（応用編）

🔹 記事タイトル例
👉「RHBKでシングルサインオン（SSO）を試してみた！」

🔹 内容

• OIDCとSAMLの違い（どちらを選ぶべきか？）
• 簡単なSSO設定（実際の設定手順）
• エラーと解決策（学んだポイントを共有）

📌 目的：RHBKを使った具体的なユースケースを紹介し、移行時のポイントを明確にする

4️⃣ RH-SSOからRHBKへの移行戦略（実践編）

🔹 記事タイトル例
👉「RH-SSOからRHBKへ！移行時のポイントとベストプラクティス」

🔹 内容

• RH-SSOからの移行パス（どんな準備が必要か）
• 設定の移行方法（Realmのエクスポート・インポート）
• 移行時の注意点（認証フローの変更、互換性問題）

📌 目的：RH-SSOからの移行に悩む人向けに、実践的なノウハウを提供する

📝 Zennでの発信戦略

✅ 週1〜2本のペースで記事公開（まずは基礎編から）
✅ 記事の最後に「次回予告」を入れて継続読者を増やす
✅ Xで学習進捗を発信し、フォロワーを増やす

🔥 「基礎 → 操作 → 応用 → 実践」の流れで記事を書けば、RHBK学習者にとって価値のあるコンテンツになるはず！

💰 有料記事のアイデア（実践編 & 体系化）

🔹 有料記事の方向性

• 無料記事で基本知識を提供
• 有料記事で「実践」「移行プロジェクト支援」にフォーカス
• 読者が「これを見れば実務に活かせる」と思える内容にする

📘 有料記事のタイトル案

「RH-SSOからRHBKへの移行ガイド（実践編）」

👉 価格イメージ：2,000円～3,000円

📌 収録内容（目次イメージ）
✅ RH-SSOからRHBKへ移行する際のプロジェクト設計

• 移行を成功させるための手順
• 事前準備すべきチェックリスト
• よくある失敗とその回避策

✅ RHBKの実務レベルでの設定方法

• RHBKの詳細な設定（OIDC, SAML, LDAP連携）
• 認証フローの設計（アカウント連携、2FAの有効化）
• パフォーマンスチューニングと運用管理

✅ トラブルシューティング集（移行時の課題と対応策）

• 企業での導入時に直面する問題と解決策
• OpenShiftとの連携時の注意点
• マイグレーションの際のデータ変換

📌 ターゲット：RH-SSOを使っている企業のSREや認証管理担当者
📌 価値：ドキュメントを読んでも分からない「実務の勘所」を学べる

📘 もう1つの有料記事案

「RHBKマスターコース：プロジェクトで使える実践ノウハウ」

👉 価格イメージ：3,000円～5,000円

📌 内容
✅ 基礎 + 応用 + 実践を体系的に学べる
✅ ハンズオン付き（例：Docker環境でのRHBK構築）
✅ 運用時のベストプラクティス

📌 ターゲット：RHBKを導入・運用するエンジニア・SRE

🎯 有料記事と無料記事の住み分け戦略

• 無料記事 → RHBKの基礎知識と簡単な使い方
• 有料記事 → プロジェクト実践・移行ガイド・運用ベストプラクティス
• Twitterやブログで無料記事を拡散し、有料記事へ誘導

🔥 「無料でまず信頼を得て、実務レベルの深い知識を有料で提供する」 というのが王道の戦略です！

OPENJDKをインストールは以下を参照してやってみる。
Docker環境で作るのは厳しそうなのでやめる。。。

https://zenn.dev/hayato94087/articles/c0345e6c2c53e7#パッケージをインストール

スタートガイドを読んで、以下まで理解。
スタートガイドの基本的な流れ、もしくは、RHBKを使ったSAMLの流れを記事にしてみるか。
⇨Xで流してみる。

はい、基本的には同一のユーザーです。
ただし、状況によっては 異なる場合もある ので、それぞれのケースを説明します。

✅ 通常のケース（ユーザーはレルムに登録されている）

レルムに登録したユーザー = アプリケーションにログインするユーザー

1. 管理者がレルムにユーザー（UserA）を作成
2. UserA がアプリケーションにログインしようとする
3. Keycloak は UserA の認証情報を確認し、ログインを許可する

+----------------------------+
|       Keycloak Realm       |
+----------------------------+
        │（1. ユーザー登録）
        ▼  
+----------------------------+
|   UserA (登録済み)         |
+----------------------------+

        │（2. アプリにログイン試行）
        ▼  
+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（3. 認証要求）
        ▼  
+----------------------------+
|  Keycloak (認証サーバ)     |
+----------------------------+
        │（4. 認証OK）
        ▼  
✅ **UserA はアプリにログイン成功！**

📌 ポイント

• レルムに登録されているユーザーのみログイン可能
• アプリは Keycloak に認証を委託し、ユーザーの正当性を確認

🚨 異なるケース（アプリにログインしようとするユーザーがレルムに登録されていない）

レルムに登録されていないユーザー ≠ アプリにログインしようとするユーザー

1. UserB（未登録）がアプリケーションにアクセス
2. アプリは UserB の認証を Keycloak に委託
3. Keycloak は「このユーザー知らん！」と拒否する

+----------------------------+
|       Keycloak Realm       |
+----------------------------+
        │  
        ▼  
❌ **UserB（登録なし）**
  （ユーザー登録されていない！）

        │（ログイン試行）
        ▼  
+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（認証要求）
        ▼  
+----------------------------+
|  Keycloak (認証サーバ)     |
+----------------------------+
        │  
        ▼  
🚫 **認証失敗！ UserB はログインできない**

📌 ポイント

• Keycloak のレルムに登録されていないユーザーは ログインできない
• もし外部IDプロバイダー（例：Google, LDAP, GitHubなど）を設定していれば、外部アカウント経由でログイン可能になる場合もある

🔍 まとめ

つまり、レルムにユーザーが登録されているか、もしくは外部IDプロバイダーで認証できるかが、アプリにログインできるかの決め手 です！

🌍 外部IDプロバイダー（IdP）を利用した認証フロー

外部IDプロバイダー（Google, LDAP, GitHubなど）を利用して Keycloak にログインし、その後アプリにアクセスする流れ

✅ 外部IDプロバイダーを利用してアプリにログインするケース

🔹 レルムに登録されていないが、外部IDでログインできるユーザー

+----------------------------+
|       Keycloak Realm       |
+----------------------------+
        │（1. ログイン試行）
        ▼  
+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（2. 認証要求）
        ▼  
+----------------------------+
|  Keycloak (認証サーバ)     |
+----------------------------+
        │（3. 外部IDへリダイレクト）
        ▼  
+----------------------------+
|  外部IDプロバイダー (Google, GitHub, LDAP, etc.) |
+----------------------------+
        │（4. 認証成功）
        ▼  
+----------------------------+
|  Keycloak (認証サーバ)     |
+----------------------------+
        │（5. トークン発行）
        ▼  
+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（6. アクセス許可）
        ▼  
✅ **UserX はログイン成功！**

🚨 外部IDプロバイダーを設定していない場合

外部IDプロバイダーが設定されていない場合、Keycloak はそのユーザーを認識できないためログインできない

+----------------------------+
|       Keycloak Realm       |
+----------------------------+
        │  
        ▼  
❌ **UserX（未登録 & 外部IDなし）**
  （ログインできない！）

        │（ログイン試行）
        ▼  
+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（認証要求）
        ▼  
+----------------------------+
|  Keycloak (認証サーバ)     |
+----------------------------+
        │  
        ▼  
🚫 **認証失敗！ UserX はログインできない**

🔍 まとめ

💡 なぜ外部IDプロバイダーを使うのか？

1. ユーザー登録の手間を省ける → 既存のGoogle, GitHub, LDAPアカウントをそのまま利用
2. セキュリティ向上 → Keycloak の管理外で MFA（多要素認証）を設定可能
3. シングルサインオン（SSO）が可能 → 1回の認証で複数のアプリにアクセス

💡 結論： Keycloak は外部IDプロバイダーと連携すれば、未登録ユーザーでもログインできるようになる！

🔐 SAML 認証を利用する場合のログインフロー

SAML（Security Assertion Markup Language）は、主にエンタープライズ向けのシングルサインオン（SSO）に使用される認証プロトコルです。
Keycloak を SAML サービスプロバイダー（SP）として設定し、外部の SAML IDプロバイダー（IdP）と連携することで、Keycloak にユーザーが未登録でも SAML IdP の認証情報でアプリにログインできます。

✅ SAML IdP を利用したログインフロー

🔹 SAML IdP（社内IdP, Azure AD, Okta など）で認証し、Keycloak 経由でアプリにログインする流れ

+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（1. ログイン試行）
        ▼  
+----------------------------+
|  Keycloak (SP: サービスプロバイダー)  |
+----------------------------+
        │（2. SAML 認証リクエスト）
        ▼  
+----------------------------+
|  外部 SAML IdP (Okta, Azure AD, etc.) |
+----------------------------+
        │（3. 認証成功 → SAMLレスポンス発行）
        ▼  
+----------------------------+
|  Keycloak (SP)             |
+----------------------------+
        │（4. SAMLレスポンスを検証）
        ▼  
        │（5. Keycloak 内部でユーザーセッション作成）
        ▼  
+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（6. アクセストークン発行 & ログイン許可）
        ▼  
✅ **UserX はログイン成功！**

🚨 SAML IdP で認証できない場合

もし SAML IdP 側で認証に失敗した場合、Keycloak はログインを許可しません。

+----------------------------+
|  アプリケーション (App)     |
+----------------------------+
        │（1. ログイン試行）
        ▼  
+----------------------------+
|  Keycloak (SP)             |
+----------------------------+
        │（2. SAML 認証リクエスト）
        ▼  
+----------------------------+
|  外部 SAML IdP             |
+----------------------------+
        │  
        ▼  
🚫 **認証失敗！ UserX はログインできない**

🛠️ Keycloak での SAML 設定ポイント

Keycloak を SAML SP（サービスプロバイダー）として機能させるには、以下の設定が必要になります：

1. 外部 SAML IdP のメタデータを Keycloak に登録
2. Keycloak を SAML SP として設定し、SPメタデータを IdP に提供
3. 適切な SAML マッピングルール（属性変換など）を設定
4. アプリ側が SAML 認証フローに対応していることを確認

🔍 まとめ

💡 SAML の利点

✅ シングルサインオン（SSO） → 企業内のユーザー管理を統一できる
✅ ユーザーの一元管理 → Keycloak に個別登録せずに IdP で認証可能
✅ セキュリティ強化 → 企業ポリシーに従った MFA（多要素認証）を適用可能

💡 結論： Keycloak は SAML IdP と連携すれば、未登録ユーザーでも SAML 認証を経由してアプリにログイン可能！

そう、そのイメージでバッチリです！ 🎯

🔍 もう一度整理すると…

1️⃣ ユーザーがアプリ（SP配下）でログインを試みる
2️⃣ SP（Keycloak）が外部IdPに認証リクエストを送る
3️⃣ IdP がユーザー認証を実施し、トークンを発行する（SAMLレスポンスやOIDC IDトークンなど）
4️⃣ SP（Keycloak）が受け取ったトークンを検証
5️⃣ SP がアプリに認証済みのユーザー情報を渡し、アプリが認可する
6️⃣ ユーザーがアプリを利用できる！ 🎉

💡 ポイントはここ！
✅ IdP は認証を担当し、トークンを発行する
✅ SP はトークンを検証し、アプリへのアクセスを制御する
✅ アプリ自体はユーザー認証を直接行わず、SP（Keycloak）を通じて認可する

この構造のおかげで、複数の外部IdPと連携しつつ、統一された認証基盤を持てるわけですね 💪🔥

🌐 RHBK（Red Hat build of Keycloak）で実現できる代表的なログインフロー

Keycloak では、以下の3つの主要な認証フローをサポートしています。

1️⃣ OAuth2.0 🔐（認可フレームワーク）
2️⃣ OpenID Connect（OIDC） 🔑（OAuth2.0の拡張で、ID情報も取得）
3️⃣ SAML 📜（XMLベースの認証プロトコル）

それぞれのフローを図示しながら、特徴や使い分けについて解説します！

🛠 1. OAuth2.0（認可フレームワーク）

OAuth2.0 は 認可（Authorization） のためのフレームワークで、アプリがユーザーの資格情報（ID・パスワード）を知らなくても、第三者サービス（IdP）経由でアクセス権を取得できる仕組み です。

📌 ログインフロー（OAuth2.0: Authorization Code Flow）

+------------------------------------------------+
| ユーザー                                       |
+------------------------------------------------+
          │（1. ログイン要求）
          ▼
+------------------------------------------------+
| アプリ (クライアント)                          |
+------------------------------------------------+
          │（2. 認可リクエスト: Keycloakへ）
          ▼
+------------------------------------------------+
| Keycloak (認可サーバ)                          |
+------------------------------------------------+
          │（3. ユーザー認証 & 認可）
          ▼
+------------------------------------------------+
| IdP (Google, Azure AD, etc.)                   |
+------------------------------------------------+
          │（4. 認証成功 → 認可コード発行）
          ▼
+------------------------------------------------+
| Keycloak (認可サーバ)                          |
+------------------------------------------------+
          │（5. 認可コード → アクセストークン発行）
          ▼
+------------------------------------------------+
| アプリ (クライアント)                          |
+------------------------------------------------+
          │（6. アクセストークンを使ってAPI利用）
          ▼
✅ **ユーザーはリソースにアクセス可能！**

🌟 メリット

✅ アプリ側はパスワードを保持しなくてよい（セキュリティ向上）
✅ シングルサインオン（SSO）と組み合わせ可能
✅ API へのアクセス制御に最適（モバイルアプリやWebアプリ向け）

⚡ 使い分け

• 認可（Authorization） がメイン（ユーザー情報の取得が目的ならOIDCが適している）
• モバイルアプリ・API にアクセスするアプリケーションに最適

🔑 2. OpenID Connect（OIDC: OAuth2.0の拡張）

OIDC は OAuth2.0 に ID情報（ユーザー情報）を付加したもの で、OAuth2.0 の「認可」に加え、「認証」もできるのが特徴です。

📌 ログインフロー（OIDC: Authorization Code Flow）

+------------------------------------------------+
| ユーザー                                       |
+------------------------------------------------+
          │（1. ログイン要求）
          ▼
+------------------------------------------------+
| アプリ (クライアント)                          |
+------------------------------------------------+
          │（2. 認可リクエスト: Keycloakへ）
          ▼
+------------------------------------------------+
| Keycloak (認可 & 認証サーバ)                   |
+------------------------------------------------+
          │（3. ユーザー認証 & 認可）
          ▼
+------------------------------------------------+
| IdP (Google, Azure AD, etc.)                   |
+------------------------------------------------+
          │（4. 認証成功 → 認可コード発行）
          ▼
+------------------------------------------------+
| Keycloak (認可 & 認証サーバ)                   |
+------------------------------------------------+
          │（5. 認可コード → アクセストークン & IDトークン発行）
          ▼
+------------------------------------------------+
| アプリ (クライアント)                          |
+------------------------------------------------+
          │（6. IDトークンでユーザー情報取得）
          ▼
✅ **ユーザーはリソースにアクセス可能！**

🌟 メリット

✅ OAuth2.0 の機能 + ユーザー情報（IDトークン）を取得できる
✅ ユーザー認証（Authentication）にも使えるため、ログインフローに適している
✅ SSO（シングルサインオン）を実現しやすい

⚡ 使い分け

• 認可だけでなく、ユーザー情報（プロフィール、メールなど）も必要な場合に最適
• シングルサインオン（SSO）を実現する際に便利
• モダンなWebアプリ、SPA（Single Page Application）向け

📜 3. SAML（Security Assertion Markup Language）

SAML は XML ベースの認証プロトコル で、主に 企業向けシングルサインオン（SSO） で使われます。OAuth2.0/OIDC よりも歴史が長く、多くの企業システムで導入されています。

📌 ログインフロー（SAML: SP-Initiated SSO）

+------------------------------------------------+
| ユーザー                                       |
+------------------------------------------------+
          │（1. SP（アプリ）にログイン要求）
          ▼
+------------------------------------------------+
| Keycloak (SP: サービスプロバイダー)             |
+------------------------------------------------+
          │（2. SAML 認証リクエストを IdP へ送信）
          ▼
+------------------------------------------------+
| IdP (Google, Azure AD, Okta, etc.)             |
+------------------------------------------------+
          │（3. ユーザー認証）
          │（4. SAML認証レスポンスを Keycloak へ送信）
          ▼
+------------------------------------------------+
| Keycloak (SP)                                  |
+------------------------------------------------+
          │（5. ユーザー認証成功 → アプリにアクセス許可）
          ▼
✅ **ユーザーはリソースにアクセス可能！**

🌟 メリット

✅ 企業向けSSOに最適（LDAPやActive Directoryと組み合わせやすい）
✅ Webアプリやクラウドサービスの統合に広く利用されている
✅ OAuth/OIDC よりも歴史があり、大規模な企業環境で安定

⚡ 使い分け

• 企業内のレガシーシステムやSaaSのSSOを統合する場合
• 大企業や政府機関など、SAMLベースのSSOが求められる場合
• OAuth2.0/OIDCに対応していないシステムと統合する場合

🔍 OAuth2.0 vs OIDC vs SAML：比較表

💡 まとめ

• OAuth2.0 → APIアクセス制御 に最適
• OIDC → ログイン＋認可（SSO向け） に最適
• SAML → 企業向けSSO（レガシーシステム含む） に最適

👉 目的に応じて適切なプロトコルを選択しよう！ 🚀

その通りです！ SAML は伝統的に XML 形式の SAML アサーション（トークン）を使用しますが、SAMLアサーションをJWT（JSON Web Token）に変換して使用することも可能 です。

✅ SAML トークンの形式

🌟 SAML + JWT のメリット

1️⃣ OAuth2.0 / OIDC との互換性向上

• 近年のシステムでは JWT ベースのトークンが主流
• SAML を JWT に変換することで、OAuth2.0 / OIDC のエコシステムと統合しやすい

2️⃣ パフォーマンスの向上

• XML は冗長で解析コストが高い
• JWT はシンプルな JSON 形式で、パースが軽量

3️⃣ モダンな API ベースの認可と統合しやすい

• 多くの API やマイクロサービスが JWT を利用
• SAML を JWT に変換することで、API やクラウドサービスとの統合が容易に

📌 SAML アサーション → JWT 変換の流れ

1. IdP（Identity Provider: Keycloak など） が SAML アサーション（XML）を発行
2. SP（Service Provider）や API ゲートウェイ で SAML アサーションを JWT に変換
3. JWT を使って API や OAuth2.0 ベースのシステムと連携

💡 どの場面で SAML + JWT を使うべきか？

✅ SAML ベースの認証を使いたいが、OAuth2.0 / OIDC の仕組みに統合したい場合
✅ マイクロサービス環境や API ゲートウェイで JWT を使いたい場合
✅ レガシーな SAML システムを最新の ID 管理システムと連携したい場合

🛠 実装例（Keycloak で SAML → JWT 変換）

Keycloak では、SAML アサーションを JWT に変換するカスタムプロバイダーや、アダプターを利用することで JWT 化が可能 です。

例えば、Keycloak の SAML Client Adapter で、JWT の生成オプションを組み込むことで実現できます。

👉 まとめると、SAML は通常 XML 形式ですが、JWT 形式でも運用可能 であり、特に モダンな認証・認可システムと統合する際に有効 です！ 🚀