久しぶりの積読消化シリーズ...！
OSS製品の本ではありますが認証、認可の切り口で学習する教材としても良さげです。今回は本の内容というよりざっと読んで得た知識で実際に手を動かしていきたいと思います。
Why Keycloak?
過去にも紹介しましたが、個人的にStrapiの認証系のOSSを公開しています。
ちょくちょく外国の方からPRが届くのですが、その中でKeycloakを使ったOIDCのものがあったのでマージ前に一度学んでおこうと思い書籍購入に至ります。
あと、この手のクラウドサービスは若干高い（個人的な感覚）のでホスティングの選択肢も増えるとシステム構成に幅が広がって、つよつよエンジニアに一歩近づけるかもしれません。
２月に買ったんですがなんやかんや放置していましたm(._.)m
Keycloakとは？という話は執筆された野村総研さんの方の記事があったのでご一読くださいませ。
セットアップ
書籍記載のバージョンから結構上がっているせいか、本の通りに..とはいかず。PCを買ったばかりということもあり、Dockerで動かすことにしました。
公式サイトのこちらに記載がありました。
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:24.0.4 start-dev
ワンライナーで立ち上がります。ユーザー名／パスワードはadminでログインできます。
realmの作成
左上のハンバーガーアイコンからCreate realm→新規でrealmを作成
ユーザー作成
まずはUsersから一般ユーザー的なものを作ります。
パスワード設定は登録後にCredentialsからできます。
Clientsの追加
早速クライアントアプリを設定します。左メニューのClientsより以下のように追加します。
登録後、Valid redirect URIsに認証元のURLを設定します。自分の場合はローカル環境のStrapiからになるのでhttp://localhost:1337/* のように記述しました。
そしてCredentialsのタブにClient Secretsがあるので、これらを使えばOpenID Connectの最低限の認証は出来ていそうです。
認証の強化 OTPを必須に
前述のような簡易的な操作であればWeb画面を見た感じで設定していくことができますが、ここからはより専門的になるので書籍に頼ります。当該章は"第７章 さまざまな認証方式を用いる"です。
先ほど作成したexample1というrealmのユーザーのログイン時に2要素認証を追加してみます。左メニューのAuthentication -> browserを選択します。
↑キャプチャの下の方、Browser - Conditional OTP Conditionalになっています。どうやらOTP設定が有効の場合はOTPの入力画面が出る、という動きをするようなのでこれをRequiredに変更します。
するとOTP登録する画面が出ました。Google Authenticatorを登録後にシークレットウィンドウなりでもう一度ログインを試みるとちゃんと入力画面になりました。
任意のユーザーのみOTPを有効に
ふと気になったんですが、特定のユーザーのみOTPを必須にできないんだろうかと疑問を持ったので検証してみます。どうやらOTPを必須にしたいユーザー向けにロールを割り当てればいけそうです。
※先ほどのOTP必須はConditionalに戻します。
まずはRealm rolesからotp_required_roleという名前のロールを作成。次に、壊れてもいいようにbrowserのフローを複製します。Authenticationのbrowserの右の方にあるDuplicateを選択して、適当にotp_required_browserとでも命名します。
ConditionalになっているOTPの設定ボタンからAdd Conditionを選択し、先に作成したロールotp_required_roleを条件にして保存します。
これで認証の設定は完了。ただし、上記はbrowserを複製したものなのでClients側でbrowserではなくotp_required_browserを利用するように変更が必要です。
Clientsからtest_client →Advancedタブの最下部にBrowser Flowという項目があったのでこちらをotp_required_browserに変更します。
この状態でもう一度ログイン操作を行い、OTPの画面が出ないでログイン突破できれば成功です。（ユーザーにotp_required_roleロールをアタッチしてないため）
ログイン突破できていれば次はotp_required_roleロールをアタッチしてOTPが出ることを確認します。Usersから当該ユーザーのRole Mappingから追加して、もう一度ログインします。
OTP出ました！成功です。
WebAuthnを有効に
続いてWebAuthnも簡単に設定できるとのことでやっていきます。
Authentication→Policies→Webauthn Policyを開くと設定項目が沢山出てきます。本にはそれぞれの説明が丁寧に書かれています。
一つだけ気になった項目、Authenticator Attachmentではスマートフォンを除く（つまりYubikeyのような取り外しできる機器のみ）ことができるようなのでキツめに縛れるのが嬉しいですかね。まあYubikey持ってないんですが...。
ポリシーの設定確認を終えたらWebAuthn用のフローを作ります。先ほど作ったotp_required_browserを複製して、otp_webauthn_required_browserという名前のフローを作成します。
先ほどと似たような手順でAdd stepからWebAuthn Authenticatorを追加します。
フローの全体はこのようになりました。
otp_required_roleロールがアタッチされているユーザーはパスワード認証後にOTP&WebAuthnが必須、ロールがないユーザーはパスワード認証のみで突破するようになっています。
また、Clientsのtest_clientにあるブラウザ認証をotp_webauthn_required_browserに変更して設定完了。
WebAuthnの初回→２回目以降の認証画面はこんな感じ
その他の気になった機能・章
第７章は他にもActive Directoryと連携したユーザーストレージフェデレーションや各SNSアカウントを使った認証フローについて詳しく記述されています。
本記事は思ったより長くなったので割愛しますが、それ以降の章には認証画面のカスタマイズ、DBの変更、クラスタ構成、バージョンのアップグレード方法といった商用環境で求められそうな内容が盛り沢山で大変興味深いです。
まとめ
書籍全体的な印象として、文章が読みやすく用語が整理されているので分かりやすいです。まあ専門用語が多いので流し読みしてページ捲ってるとすぐに混乱しますが、読んでても雰囲気で満足した気にならないので技術書としては良いことかなと思いますw
Yubikey、ちょっと欲しくなってきましたが手軽な分、紛失が気になるところです。たまに外出先にPC持っていく時に忘れると強烈に不便さを感じそう。じゃあ差しっぱなしにするかというと微妙で、Yubkeyをセキュリティの高さに重きを置いているユースケースでは利便性が損なわれるのが普通なのかなと( ´Д`)y━･~~
WebAuthnは何年か前に自前で実装して検証してた時は結構面倒な印象があったので、画面ぽちぽちで設定できるのはポイント高いですね。
以上、良書紹介でした
