概要

自前の認証機能を持っていない、既存のウェブサイトや独自アプリがある
Basic認証などで都度ID/パスワード設定するのは古臭いし管理たいへんなので止めたい
シングルサインオンできる 自前の認証機能 を使いたい

はじめに

この記事は以下の続編です。

OAuth2で「外部の」認証基盤を利用する仕組みは出来た。
Keycloakで「自前の」認証基盤立ち上げは出来た。

なので、（満を持して）自前の認証基盤でSSOできる仕組みへ移行。

設定の流れ

OAuth2 Proxyのドキュメント確認

ドキュメントの Keycloak OIDC Auth Provider の項を見ておく。
この項と別に Keycloak Auth Provider という項もあるが、冒頭のnoteに「こっちは古いやつ」って書いてあった。

Keycloakの設定

Realmの追加（任意）
クライアントの作成
secretを控える
mapperの作成（2個）

Realmの追加

Realmは、まだ運用シナリオも決まってないので、とりあえず今回用に新規作成した。
「クライアント」を複数作成できるようなので、そもそもそんなに分離する必要もないのかもしれない。

クライアントの作成

Clientsタブに移動し、右上の「Create」ボタンを押す。

任意のClient IDを入力して追加。

OAuth2 Proxyのドキュメントには「Access Type 'confidental'」で作成しろって書かれているけど、作成画面には無い。。
と思ったら、作成後の設定画面にあった。

「Valid Redirect URL」には、Github版で指定したのと同じリダイレクト先を指定。
（OAuth2 Proxy側で設定済み）

https://example.com/oauth2/callback

secretを控える

Credentialsタブに移動し、記載されているsecretを oauth2-proxy.cfg に転記する。

mapperの追加

Mappersタブに移動し「Create」ボタンを押す。
Mapper Typeとして、以下の2つを作成しろとある。

Group Membership : Token Claim Name = 'groups' とする
Audience : Included Client Audience と Included Custom Audience に、作成したクライアント名を追加する

ここまで、わけもわからずドキュメントの指示に従って作業しただけ。

http_address = "127.0.0.1:3333"
reverse_proxy = true
redirect_url = "https://example.com/oauth2/callback"
upstreams = [
    "http://inside.example.com/"
]
header = true
pass_host_email_domains = [
    "your-mail.example.com"
]
provider = "keycloak-oidc" ★
client_id = "oaproxy-app" ★
client_secret = "xxxx" (Credentialsタブからの転記) ★
oidc_issuer_url = "https://keycloak.example.com/auth/realms/practice1800" ★
cookie_secret = "xxxx"

★をつけたところが、Github版から変更された行

認証設定の確認

oauth2-proxyコマンドを再起動。

InPrivateウィンドウを開いて、未認証状態から認証開始してみる。

あれれ...？？

あっ、そうかこれ、master Realm（Keycloakの管理用Realm）とは別に作成したので、同じユーザーで入れないということか。。

とりあえず別名でアカウント追加してみる。

パスワードを設定。Temporaryはオフに。

このアカウントの他の設定:

your-mail.example.com ドメイン配下のEmailアドレスを登録（pass_host_email_domainsへの対応）
Email Verified 項のスイッチを「ON」にする。

設定したユーザIDとパスワードでログインすると、アプリへのログインができた。

ヘッダに落ちてくる情報がだいぶ変わった。

/apps/env.cgi

HTTP_X_FORWARDED_EMAIL => 'k2ok@your-mail.example.com',
HTTP_X_FORWARDED_FOR => '127.0.0.1',
HTTP_X_FORWARDED_GROUPS => 'role:offline_access,role:default-roles-practice1800,role:uma_authorization,role:account:manage-account,role:account:manage-account-links,role:account:view-profile',
HTTP_X_FORWARDED_HOST => 'example.com',
HTTP_X_FORWARDED_PREFERRED_USERNAME => 'k2ok-app',
HTTP_X_FORWARDED_USER => '161d332a-9f29-4da0-a004-471465e6535d',

HTTP_X_FORWARDED_USER が、アカウント名ではなくuuidらしき文字列になっている。
同じアカウント名であっても、過去のユーザーとは紐づかないということか。。

Realmに関する情報がヘッダに含まれていないが、 oidc_issuer_url で認証の依存先は明示しているので、
他の認証プロバイダとのフェデレーションが出来るということは、おそらく同じKeycloakベースの異なるRealm間のフェデレーションも出来るんじゃないかと思われるが、どこまで同じユーザーが一意に定まるのかは調査が必要そう。

今回の設定から足りていないと思われるところ

とりあえず管理画面強制で逃げてしまったが、KeycloakのEmail Validationを促すためのURLパラメータがOAuth2 Proxy側にあるんじゃないだろうか。
また、Keycloak側では新規ユーザの登録を受け入れる仕組みがあって、Realmで受付許可設定ができるので、これに対応するURLの指定もOAuth2 Proxy側にあると思われる。

感想

Keycloakはきめ細かい権限分離がいろいろ出来るようだが、全容を押さえるのはかなり難儀しそうに感じた。

この認証基盤を活かせるほどの大量のミニアプリが存在する会社というのは、どれくらいあるんだろうか。。

OAuth2 Proxyで外部認証(2) Keycloak編

概要