関連スライド
各ページのテキスト
現物確認のススメ 情報は足で稼ぐ。 chota60
はじめに 自慢じゃないかも・・・（不安）
はじめに 自慢じゃないかも・・・（不安） こまけえことはいいんだよ！って人むけ です！
Who? - chota60 - ギフティ - 共通IDの運用・保守 - 最近はチルめな音楽が好き
Who? - chota60 - ギフティ - 共通ID群の運用・保守 - 最近はチルめな音楽が好き
目次 - 共通ID群を実現する Keycloak - Keycloak 運用のお仕事 - 現物確認のススメ
共通ID群を実現する Keycloak
共通ID - 異なるアプリケーション間で共通の認証情報を扱う箱 - 利用者は一度のログインでアプリケーション群を利用できる - 例：リクルートID、楽天ID、Google アカウント
共通ID群 例えば以下のように複数の向き先、複数のサービス群を扱っています - 個人向け : giftee.com - 法人向け : giftee for Business - 自治体向け: 旅先納税 ※あくまでイメージ
ギフティから個人が購入し、個人が受け取る（BtoCtoC） https://giftee.com/about
ギフティから法人が購入し、個人（従業員や顧客）が受け取る（BtoBtoB/BtoBtoE） https://giftee.biz/about/
ギフティから自治体が購入し、個人（旅行者など）が受け取る（BtoGtoC） https://giftee.co.jp/pressrelease20221102_01/
共通ID群 ギフティのサービスには、多様な利用者がいる - 発行する人も異なれば、受け取る人も異なる - 共通IDが必要な場合もあれば、不要な場合もある - 一緒にすべき場合もあれば、分けるべき場合もある この複雑さがギフティにおける共通 IDの難しさであり、面白さです
共通ID群を支える Keycloak - ギフティのサービスは基本的に薄利多売型 - MAU 課金な Auth0 などの IDaaS はアンマッチ そのためギフティでは、 Keycloak という OSS を採用しています
Keycloak - Identity and Access Management を実現する OSS - CNCF Incubating - マルチテナント対応 - コンテナ環境に適合
Keycloak 共通IDを柔軟に実現するOSS - 容易なセルフホスティング - 柔軟なテナント設定 - 組み込みだけで提供可能な様々な認証方法
ちょろっと demoします
Keycloak 運用のお仕事
ワンストップなソリューション 導入から運用・保守まで伴走します - 仕様検討・フィージビリティ検証 - インフラ構築 - UI作成 - テナントの作成 - 連携のための初期設定の実施 - サービスイン後の保守 - アップグレードなどの運用
Keycloak は柔軟 選択可能な設定が盛りだくさん - 認証情報の連携プロトコル - テナントの定義 - ユーザーの属性 - 認証フロー、MFA、アカウントロックなど
「なんでもできる」というのは自由ではない なんでもできるというのは、選択肢が存在しないのと同じです 少しでも負担をなくすため、弊 Keycloak では制約を設けています
アプリケーション連携のための制約 SAML, OpenID Connect, OAuth を用いた認証など様々な方法が存在 ↓ 実質デファクトである、 OpenID Connect 1.0 を採用 +認証フローは特別な事情がない限り、認可コードフローのみ対応
ユーザー属性はビジネス要件と割り切る 原則「やらないこと」として下記のポリシーを掲げています - 認可判断は行わない - ユーザーの属性情報を保持しない - クライアント独自の対応はしない あくまで「認証」に特化した薄い基盤として立てています
個別対応という苦難 繋ぎ方は決まっていて、できる範囲も決まっている それでも個別対応が必要になる局面が存在します
かんたん
UI まずはシンプルにこれ - アプリケーションは自分たち用の画面が欲しいがち - 共通のUIしかできない、ということは訴求力を失う - デザインをいい感じにする、というのが必須のタスクになる
初回ログインフロー 稀に良くあるケース - 利用規約を読んで欲しい - メールアドレスを登録して欲しい - パスワードを変更して欲しい（初期パスでログインした場合）
これらは調査すればなんとかなる 大体ドキュメントに書いてある - 公式ドキュメント - 公式 Slack - 公式 discussions
公式ドキュメント：Server Administration Guide https://www.keycloak.org/docs/latest/server_admin/index.html
discussion の一例 https://github.com/keycloak/keycloak/discussions/8962
むづかしい
認証方法のカスタマイズ 難易度が高いケースの代表例 - 2段階認証を入れたい - 「特定の IdP でログイン」を入れたい - 特殊な拡張がはいった SAML 認証でログインさせたい
そのほかにも まだまだある、謎の要望（謎ではない） - ログインなど特定のイベントをメール通知させたい - メールアドレスだけで仮登録するフローを組みたい - 合言葉を知っている人だけに登録させたい - 連番のパスワードを使いたい（ majiska ? ）
こ、困る・・・
どうするか
現物確認のススメ
一般的な情報は n 次情報 Qiita や Zenn の記事は、何次情報かわからないほど間に年月や文脈が挟 まっています LLM による情報も同様です 何より、公式ドキュメントですら、一次情報にすぎません より確実な情報が欲しいなら、 零次情報 にあたるべきです
零次情報としてのコード プログラムを定義しているコードは、ドキュメント以前のドキュメントです それで動いているなら、それを見るのが確実です
零次情報としてのコード そもそも、OSS はコードが公開されています ならそれをみるのが、確実です！
聞いてみたこともある ドキュメントにはこの情報なさそうなんだけど、どゆこと？ と聞いたら、実装みるといいよってコミュニティの方に言われました この経験に影響されてたりもします
質問したことがある回（CNCF の Slack）
二つ、方法を紹介します - 由緒正しきデバッグ - 最近のメタ
由緒正しきデバッグ Keycloak は Quarkus というフレームワークでできた Web アプリ →つまり、ローカルでデバッグできる！
IDE を使ったデバッグ 詳しい方法は割愛しますが、IDE の機能を使えばデバッグできます
ビルド時に生成される Dockerfile を編集 FROM registry.access.redhat.com/ubi8/openjdk-21:1.18 ENV LANGUAGE='en_US:en' # We make four distinct layers so if there are application changes the library layers can be re-used COPY --chown=185 target/quarkus-app/lib/ /deployments/lib/ COPY --chown=185 target/quarkus-app/*.jar /deployments/ COPY --chown=185 target/quarkus-app/app/ /deployments/app/ COPY --chown=185 target/quarkus-app/quarkus/ /deployments/quarkus/ EXPOSE 8080 USER 185 ENV JAVA_OPTS_APPEND="-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager" ENV JAVA_APP_JAR="/deployments/quarkus-run.jar" # この設定を入れることで、 5005 ポートがデバッグ用のポートになる ENV JAVA_TOOL_OPTIONS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005" ENTRYPOINT [ "/opt/jboss/container/java/run/run-java.sh" ]
あとは素直に # docker image の build docker build -f src/main/Docker/Dockerfile.jvm -t sample-quarkus --platform linux/arm64/v8 . # 5005 port を開放して起動 docker run -i --rm -p 8080:8080 -p 5005:5005 sample-quarkus
ただし 実はもうこの手法は使っていません 前述のデバッグ手段も、現在も使えるか微妙かも・・・
現代のメタ＝生成 AI まあやっぱ楽なんすよね（堕落）
生成AIに聞いてみる まあ手法として一定強そうです GPT 4.2 あたりから普通に Keycloak のことも知っています が、あくまで集合知に過ぎないので、これでも足りない場合があります
例題 - Keycloak には、パスワード再設定の機能があります - 基本的にはログイン画面から遷移できるようになっています - この時、ログイン時専用のセッションも引き継がれます → 「あれ？じゃあ固定のpathで遷移できるの？🧐」 固定のpathで遷移させられるなら、ユーザー移行の時に使えるはず・・・調べ たいなあ・・・
Gemini によると、結論らしい
ほんまか？
色々言われると怪しく見える
より正確な情報のためには？ なんの文脈も持たない生成 AI は集合知から答えを出します が、我々は集合知がカバーしているかわからない機能を探しています したがって、こんなものはアテにすべきではありません（断言）
そう、コードです OSS はコードが公開されています ということは、生成 AI の手がとどくところにコードをおいて、調査して貰えばい いわけです
というわけで、リトライ！
良さそう なんかいけそうじゃね？ でも無根拠に言ってるんじゃねえの？
色々な探し方をしている、の図
良さそう テキトーに言ってるわけじゃなかった！ 実際この返答に合わせて調べると、すんなりいけました 結局動くコードが全てであり、それに近い手法をとるべき その現物を確認するためのバフとして生成 AIは活用できる と言えそう
まとめ
話したこと - 共通ID群を実現する Keycloak - Keycloak 運用のお仕事 - 現物確認のススメ
大事にしていること - 生成AIの言うことを鵜呑みにしない - 実際に動かして試した情報が一番 - 実際のコードを解析した情報が二番
確実さはどの時代も大事 結局、確実な情報が一番大事 取れる手法は全てとる それでアプリケーションや利用者が得すればハッピー こういうメンタリティで今後もやっていこうと思います
Thank you !