概要
Cognitoの基本的な用語や設定については割愛します。
今回は、Cognitoと外部Idp経由(SAML)での認証の仕組みを構築したときのポイントについて説明します。イメージは以下のようになります。ユーザープールのフェデレーションの仕組みを活用、外部Idpと連携することで、認証処理そのものはIdp側におまかせすることになります。
設定方法
外部Idpの設定
ここでは省略します。設定後、外部Idp側からSAML設定用のメタデータドキュメント(XML)を入手しておきます。
Cognitoの設定(主な設定項目のみ)
| カテゴリ | 設定項目１ | 設定項目２ | 値 |
|---|---|---|---|
| 全般設定 | アプリクライアント | トークンの有効期限を更新 | デフォルト(30日) |
| アクセストークンの有効期限 | 720分 | ||
| IDトークンの有効期限 | 720分 | ||
| アプリの統合 | アプリクライアントの設定 | コールバックURL | https://xxxx/oauth2/idresponse |
| サインアウトURL | システムに独自の値。 | ||
| 許可されているOAuthフロー | Authorization code grant, Implicit grantにチェック。 | ||
| 許可されているOAuthスコープ | phone,email,openid,aws.cognito.signin.user.admin,profileにチェック。 | ||
| ドメイン名 | プレフィックスを指定。実際にはアクセスするURLとしてDNS登録する。DNS登録されたURLをSAML構成時のエンティティIDとしてIpdと連携する。 | ||
| フェデレーション | IDプロバイダ | Idpから入手したメタデータドキュメントをアップロードしてプロバイダを作成。 | |
| 属性マッピング | Idp側の属性をCognitoのユーザープールの属性にマッピング。 |
ALBの設定
今回は、ALBとCognito認証を組み合わせています。ALBにリクエストが来た場合にCognitoで認証をかけます。ALBからリスナーを追加。追加したリスナーのルールを設定します。
ルールの条件を指定して、
ヒットさせる条件としては、パスでもHTTPヘッダの中身でもなんでも構いません。
アクションで認証を選択して、
認証で Amazon Cognito(ユーザープールIDとクライアントID)を選択します。スコープに openidとaws.cognito.siginin.user.adminを指定します。アプリクライアントのスコープの設定と合わせる必要があります。
それからCognito認証がパスしたあとの転送先(ターゲットグループ)を指定します。
これでALBにリクエストが来ると、条件にヒットしたときに Cognito 認証を通ることになります。
ポイント
-
ユーザ情報
外部Idpでの認証が成功すると、Cognitoのユーザープール内にユーザ情報が保存されます。保存された情報は、Cognito→ユーザプール→全般設定→ユーザとグループの設定から参照できます。万が一ユーザ情報がおかしくなってしまった場合は、ユーザ情報を無効化してから削除すると解決するケースがあります。 -
タイムアウト制御について
外部Idp側でユーザ名とパスワードを入力するのですが、そこでしばらく放置(10分程度)しているとCognitoの呼び出しがタイムアウトします。Cognito側でのタイムアウト制御ができないため、ここは泣く泣く運用で回避しました。 -
サービスクォータ
秒間で数千くらいのリクエストを想定していたため、サービスクォータの上限緩和を申請したところあえなく却下。AWSのサポート担当の方曰く、トークン自体もある一定期間は保持されること、また数千万のユーザを抱えるアカウントでも1秒あたり1000リクエスト以下で運用可能であるから、という理由でした。
Cognitoと外部Idpとの連携については、以上です。
これ以外にも、認証をパスしたあとで、認証付きURLを用いてS3へのアクセス制御をしたのですが、それについてはまた別途。