AWS 上で構築しているアプリを LDAP 認証に対応させようとしたら、今風の(と思われる)方式がなかなかに深かったので覚書です。
背景として以下のような状況があり、AD サーバによる LDAP 認証を追加することを考えます。
- ALB で複数のアプリへ振分
- ALB で SSL 終端
- 社内の既存の AD サーバによる認証を追加 [New]
なお、記事が長くなったので具体的な設定手順やハマりポイントなどの話題を関連記事として切り出しました。
LDAP シンプルBIND方式と dexidp (予定)
～～
さて、ALB と認証周りについて調べてみると ALB による認証連携の機能があり、LDAP や AD との連携もできそうなことが書かれています。
Application Load Balancer を使用してユーザーを認証する
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/listener-authenticate-users.html
ただ、実際には ALB が対応しているのは Open ID Connect (以下、OIDC) の連携のみで、OIDC に対応した IDプロバイダ(IdP)、もしくは Amazon Cognito と連携するしかなさそうです。
そこで、OIDC <-> LDAP のプロトコル変換する方法がないかと調べたところ、行きついたのが以下の dexidp というツール。
dexidp
https://github.com/dexidp/dex/releases
OIDC のフローを介して、認証処理本体を LDAP や Google 認証など複数選択式にすることができるようです。
ユーザを認証して ID 情報を提供するエンドポイントを OpenID Provider(OP) とか ID Provider(IdP) のように表記し、dexidp はこれにあたります。
ここでは dexidp を用いて以下のような認証環境を構築してみます。
具体的な手順についてはこちらにまとめます。
ALB による OIDC の認証連携のシーケンスは以下のようになりました。
※あまり図的に説明した情報が見つからなかったので自分で作成することに。。
OIDC ではクライアントになるアプリ＝ Relying Party(RP) が、IdP から返ってきたアクセストークンを検証したり、属性情報を問い合わせたりするのですが、AWS ALB では ALB がこれを代行してくれます。
RP の振る舞いについては、以下の記事で実験をされていて分かりやすかったです。
OpenID Connect体験
https://qiita.com/sonedasaurus/items/753a65186f1be7185b39
ちなみに、今回初めて OIDC = OpenID Connect というキーワードを知りました。
LDAP 認証連携なんて一般的な方法で簡単に連携できるだろうと考えていたら、時代は先に進んでいました。。汗
個々に ID＋パスワード による認証から、認証は Google や Facebook のようなプロバイダに集約して、アプリ間で属性情報をやりとりする形に向かっています。
OIDC については、下記のサイトで背景などが説明されていて分かりやすいかと思います。
第一回 認証基盤のこれからを支えるOpenID Connect
https://www.ogis-ri.co.jp/otc/hiroba/technical/openid-connect/chap1.html
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
https://www.sakimura.org/2012/02/1487/
なお、ALB による OIDC 連携では以下のような制約がありました。
- IdP のドメインの正式証明書が必要(オレオレ証明不可)
- IdP は HTTPS 必須
- アプリ側はオレオレ証明可
- ALB の外部用/内部用はいずれも可
今回のように LDAP 連携だと社内利用などのケースが多く、内部ドメインを使ってたりするとハマりポイントかもしれません。
また、IdP(dexidp)に正規の証明書を設定し、社内アプリ用の ALB と別建てする場合はアクセス制限で ALB→ALB な疎通を通しておくのも注意です。