ADFSとCognito Userpoolsの連携 | 豆蔵デベロッパーサイト

庄司です。

ブラウザなどの UI からアクセスするマイクロサービスでは JWT 認証 (OpenID Connect 等) を利用することが一般的です。AWS を利用している場合には、Amazon Cognito user pools (Cognito Userpools) で JWT の発行が可能です。

Cognito Userpools を利用する場合には、システムにアクセスするユーザーをこのサービスに登録する必要があります。しかし、組織内の Active Directory を ADFS (Active Directory フェデレーションサービス) を使用して SAML2 の IdP (identity provider) として実行し、Cognito Userpools に ADFS を ID プロバイダーに追加することで、ユーザー情報の移行が不要になります。

この記事では、ADFS と Cognito Userpools の属性の連携について説明します。

Cognito Userpools の ID プロバイダーに ADFS を設定する方法については、参考記事を最後の方にリストしていますので、そちらを参照してください。

ADFS の設定

Cognito Userpools では、多くの場合 email 属性を必須にします。したがって、Active Directory に登録されているユーザーの電子メールアドレスを連携するように ADFS を設定する必要があります。ここでは、Windows Server にインストールされた ADFS を例に説明します。

「AD FS の管理」から「証明書利用者信頼」にある「要求発行ポリシーの編集」をクリックし、画面にある「規則の追加(A)...」ボタンをクリックします。

ステップ「規則の種類の選択」では、「LDAP 属性を要求として送信」を選択します。

要求規則名は任意ですが、この例では「Email」と入力します。属性ストアは「Active Directory」を選択します。LDAP 属性は「E-Mail-Addresses」を選択し、出力方向の要求の種類は「電子メールアドレス」とします。

出力方向の要求の種類には、後述する属性マッピングで使用する URI を入力することもできます。例えば、Title (役職) を urn:custom:jobTitle とする場合は、出力方向の要求の種類には「urn:custom:jobTitle」と入力します。

ここまでのように、規則を作成することで属性を連携することが可能になります。Cognito Userpools でカスタム属性を使用している場合には、これらの属性のマッピングも必要になります。マッピング可能な例としては、 Department (部署)、Title (役職) や EmployeeNumber (社員番号) など Active Directory で管理している LDAP 属性があります。どのような属性があるかについては「PowerShellによるActiveDirectory管理
― ユーザー管理編」等を参照してください。

Cognito Userpools の設定

Cognito Userpools の username にマッピングされる属性は「Specifying identity provider attribute mappings for your user pool」にある通り規定されています。SAML を使う ADFS の場合は、NameID がマッピングされます。

ADFS で設定した属性を Cognito Userpools にマッピングする時には、AWS コンソールの Cognito の「ユーザープールの管理」でユーザープールを選択し、「フェデレーション」にある「属性マッピング」から、「SAML」タブで SAML プロバイダー名を選択して、「SAML 属性」に ADFS で設定した出力方向の要求の種類を表す URL を設定し、ユーザープール属性には、Cognito Userpools の属性を設定します。

例えば、出力方向の要求の種類が「電子メールアドレス」の場合は、「The Role of Claims」から SAML 属性に設定する URI は http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress になり、ユーザープール属性に「Email」を選択します。

出力方向の要求の種類に「urn:custom:jobTitle」を使用し、Cognito Userpools にカスタム属性として custom:jobTitle を設定している場合は、SAML 属性に urn:custom:jobTitle、ユーザープール属性に「custom:jobTitle」を選択します。

Cognito Userpools のトークン生成前の Lambda トリガーの活用

AWS の特徴として Lambda を使ってさまざまなイベントに対処できる点があります。Cognito Userpools も例外ではなく、いくつかのイベントに対応する Lambda を定義できます。

ここでは、その中から「トークン生成前の Lambda トリガー」のユースケースを例示します。

トークン生成前の Lambda トリガーは、OpenID Connect 仕様にある ID トークンの生成前に実行される Lambda を定義します。この Lambda により、ID トークンをカスタマイズできます。

トークン生成前の Lambda トリガーのリクエストには、マッピングされた属性値が含まれます。したがって、属性値によって管理者とゲストのようにロールを割り当てるようなロジックを定義できます。そして、次のようなレスポンスを返す Lambda を定義することで、ID トークンのペイロードに "custom:role": "Admin" を追加するような要件に対処できます。

{
    // 省略

    "response": {
        "claimsOverrideDetails": {
            "claimsToAddOrOverride": {
                "custom:role": "Admin"
            }
        }
    }
}

まとめ

この記事では、ADFS と Cognito Userpools で属性の連携について説明しました。Okta、Auth0 などの IDaaS や Keycloak などでも Cognito と同様に属性のマッピング機能を使用可能です。