Azure ADをIdPに設定してALBでユーザ認証してみました。
追記(2020-03-16)
ユーザークレーム(x-amzn-oidc-data)のexpireは2分のようですが、アクセストークン(x-amzn-oidc-accesstoken)のexpireは初回ログイン時から変わらない(=期限切れになる)ようです。
- IdP によって ID トークンに有効な更新トークンが提供されている場合、ロードバランサーは更新トークンを保存し、アクセストークンの有効期限が切れるたびにこれを使用して、セッションがタイムアウトするか、IdP の更新に失敗するまで、ユーザークレームを更新します。
上記リンクのAWSのドキュメントの記述とちょっと合わない感じがしますが、バックエンド側はドキュメント記載の通りユーザークレームでユーザ認証するのであれば問題ないのかな?
手順
- HTMLを出力するLambdaを作成し、ALBのターゲットに設定する
- Azure ADにアプリケーションを登録する
- ALBを設定する
- テストする
1. HTMLを出力するLambdaを作成し、ALBのターゲットに設定する
以下記事を参考に、Lambdaを作成してALBのターゲットに設定します。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/lambda-functions.html
ALBのリスナーはHTTPSに設定し、Route53にALBのエイリアスレコードを登録します。
def lambda_handler(event, context):
print(event)
res = {
"isBase64Encoded": False,
"statusCode": 200,
"statusDescription": "200 OK",
"headers": {
"Set-cookie": "cookies",
"Content-Type": "text/html"
}
}
res['body'] = """<html>
<head>
<title>hello world</title>
</head>
<body>
<h1>Hello World</h1>
</body>
</html>"""
return res
2. Azure ADにアプリケーションを登録する
Azureにログインして、Azure Active DirectoryーApp registrationsからアプリケーションを登録します。
Redirect URIは以下を指定します。
https://Route53に登録したALBのエイリアスレコード/oauth2/idpresponse
次にアプリケーションのクライアントシークレットを作成します。
最後に各種エンドポイントを確認します。
下記コマンドでも確認できます。
curl https://login.microsoftonline.com/********-****-****-****-************/v2.0/.well-known/openid-configuration
3. ALBを設定する
ALBのリスナーを編集して、Authenticateアクションを追加します。
ALBの設定値 | 対応するAzure側の値 |
---|---|
Authenticate | OIDC |
Issure | Authorization endpointの"/oauth2/v2.0/authorize"の部分を"/v2.0"で置換したURL |
Authorization endpoint | OAuth 2.0 authorization endpoint (v2) |
Token endpoint | OAuth 2.0 token endpoint (v2) |
User info endpoint | https://graph.microsoft.com/oidc/userinfo |
Client ID | Application (client) ID |
Client secret | 作成したシークレット |
4. テストする
ALBのエイリアスレコードをURLに指定するとサインイン画面が表示されます。
サインイン後、Lambdaが出力するHTMLが表示されれば成功です。
CloudwatchLogsを確認すると、アクセストークン等が渡されているのが分かります。
雑感
- 慣れてしまえば設定はとても簡単です。(多分)
- OpenID Connectで認証するがブラウザ・ALB間はアクセストークンでなくセッションクッキーでセキュリティを担保する方式は、アクセストークン漏洩の問題がなくてなんかいい感じ。