IAM Identity CenterとAzure ADでシングルサインオン
目次
- 目次
- はじめに
- シングルサインオン構成の流れ
- シングルサインオン対象のユーザー範囲
- 自動プロビジョニング対象とするユーザーの絞り込み
- 自動プロビジョニング対象とするユーザー属性の絞り込み
- SAMLとSCIMの構成完了後の設定
- まとめ
はじめに
※2022/07 AWS SSOがIAM Identity Centerに名称変更されたため、記事を加筆・修正
こちらの記事でIAM Identity Center(旧AWS SSO)を利用して、複数AWSアカウントのマネージメントコンソールへシングルサインオンを行う構成について記述しました。今回は、Azure ADをIDプロバイダーとして利用してIAM Identity CenterとSAML連携し、Azure ADに登録されたユーザーIDでAWSへログインする構成について、詳細な設定に踏み込んで説明します。
なお、本記事ではAzure ADをIDプロバイダーとして利用する構成としていますが、これは世の中のエンタープライズの企業様の多くがActive Directoryでのユーザー管理を従前から実施されており、その流れでAzure ADを利用されているパターンが多く見受けられるためです。IDストアとしてOktaを利用することもあるでしょうし、IAM Identity Center自体にもローカルIDストア(Identity Center ディレクトリ)を無料で作成することが出来ますので、システムの要件に応じてユーザー管理をどこで行うかを選択すると良いでしょう。
機能が豊富だが有償のサードパーティサービスまでは不要なので、AWSだけで認証機能とIDストアを賄いたいという場合は、IAM Identity CenterのIdentity Center ディレクトリは選択肢になります。Identity Center ディレクトリではMFAデバイスによる多要素認証の設定も可能なため、IDストアとして最低限の機能は揃っており、今後も開発が進んでいくものと思われます。
シングルサインオン構成の流れ
SAMLメタデータの交換
IAM Identity CenterとAzure AD間でシングルサインオンを構成するためには、Azure AD側でテナントにエンタープライズアプリケーションを作成する必要があります。エンタープライズアプリケーションを作成する流れは世の中で他に情報があるため省略するとして、シングルサインオンを構成するためにメタデータファイルを交換する流れを説明します。
- Azure ADでエンタープライズアプリケーション作成後に、シングルサインオンのメニューからフェデレーションメタデータXMLをダウンロードする。
- IAM Identity Centerでアイデンティティソースの変更を行い、外部IDプロバイダーを選択して、サービスプロバイダーのメタデータをダウンロードする。
- Azure ADのエンタープライズアプリケーションで、IAM Identity Centerから入手したメタデータファイルをアップロードする。
- IAM Identity CenterでもAzure ADから入手したアイデンティティプロバイダーのメタデータファイルをアップロードする。
SAMLメタデータには、お互いの真正性を確認するための証明書やユーザーアクセス時のリダイレクト先URLが含まれます。
この作業を行うことで、SAMLプロトコルによって最低限の認証時リダイレクトの構成が完了します。
なお、IAM Identity CenterのIdentity Center ディレクトリを利用する場合はクラウド間のSAMLの構成は不要となり、ローカルIDストアに登録されたユーザー・グループ情報を利用して、すぐにログインしたいAWSアカウントとアクセス権限セットの紐づけを行うことが出来ます。
SCIMでユーザー・グループ情報の自動プロビジョニングを構成する
SAMLでの認証を行うには、IAM Identity CenterにもAzure ADに登録されたユーザーと同等のユーザー情報が存在している必要があります。
ユーザーの二重管理をしたくないからシングルサインオンを構成しているのに結局ユーザーの作成が必要なのかという感覚を受けますが、ユーザー認証の順番として、まずユーザーがIAM Identity Centerポータルにログインする際にAzure ADの認証画面に飛ばされ、そちらで認証が成功すると、認証が成功したユーザーに対応するユーザーがIAM Identity Center側にも存在する場合ログインが完了するという流れになるため、対応するユーザーの作成は必須です。
しかし、少数のユーザーID情報を手動作成=手動プロビジョニングするならまだしも、数万人登録されているようなIDストアのユーザー情報を全てIAM Identity Center側にも手動で作成するのは現実的ではありません。そのような場合にSCIMによるユーザー・グループ情報の自動プロビジョニングが有効な手段になります。
IAM Identity Centerで自動プロビジョニングを有効化する操作を行うと、SCIMエンドポイントとアクセストークンが入手できます。この情報をAzure ADのエンタープライズアプリケーション側のプロビジョニングメニューでテナントのURLとシークレットトークン欄にペーストし、プロビジョニングモードを自動にして保存すれば自動プロビジョニングが有効になります。自動プロビジョニングが有効の場合、40分の固定間隔でAzure ADからIAM Identity CenterのIDストアにユーザー情報が同期され、ユーザーの作成・更新・削除の変更が反映されます。なお、40分間隔の自動同期のみでなく、手動で変更されたユーザー情報の同期を行うことも可能です。
シングルサインオン対象のユーザー範囲
これまでの手順で、Azure ADのユーザーIDでIAM Identity Centerにシングルサインオンするための構成が整いました。しかし、シングルサインオン対象のユーザーの指定はどのように行うのでしょうか。
Azure ADでは二つの設定箇所でシングルサインオンを行える対象ユーザーの範囲を指定できます。一つ目はエンタープライズアプリケーションのプロパティメニューで[割り当てが必要ですか？]の設定値を[いいえ]にすると Azure ADテナント配下に登録されたユーザー全員がSSO対象となります。[割り当てが必要ですか？]の設定値を[はい]にするとエンタープライズアプリケーションの中の[ユーザーとグループ]内で指定したユーザー・グループのみがSSO対象となります。ただし、いずれのケースもIAM Identity Center側でも対応するユーザーを作成しないと、SAML認証だけ出来てその後はエラーが表示されます。
[割り当てが必要ですか？]の設定値を[はい]にした場合、[ユーザーとグループ]の項目で、SSO対象と自動プロビジョニングのユーザー・グループを絞り込むことが出来ます。
ただし、SAML連携自体はAzure AD Freeでも可能ですが、Azure Active Directory Premium P1以上あるいは同等(Microsoft 365 E3等)のライセンスがグループに追加されるユーザーに付与されていないと、SSO対象にグループ単位での割り当ては出来ません。
IAM Identity Centerでシングルサインオン構成を行う際にやりたくなるのは、ユーザー情報だけ外部IDプロバイダーから取得して、ユーザーのグループ管理はIAM Identity Center側で独自に行うという形です。しかし、これはIAM Identity Centerの仕様として出来ず、グループ構成から外部IDプロバイダー側で作成し、それをSCIMで同期してくる必要があります。アイデンティティソースを外部IDプロバイダーに変更してしまうと、IAM Identity Centerではユーザー・グループ共に自身では作成できないのが仕様となります。
また、ユーザーをSSO対象に追加しない状態でSSOを行おうとしても管理者がユーザーを割り当てていないため、サインイン中に問題が発生しました、とエラーとなります。
自動プロビジョニング対象とするユーザーの絞り込み
SAMLでのSSO対象とするユーザーの絞り込み方については先述の通りですが、記載した通りSAML認証の対象にしただけではSSOは成功しません。IAM Identity Center側にも対応するユーザーを作成しないといけませんが、自動プロビジョニングの場合、どのように同期対象のユーザーを指定するのでしょうか。
先ほどSCIMのシークレットトークンを張り付けたのと同じページに[プロビジョニングの編集]ボタンで移動し、[範囲]を[すべてのユーザーとグループを同期する]にすると、Azure ADテナント配下に登録されたユーザー全員分の情報がIAM Identity Centerに同期されます(数万人登録されているテナントでこれを誤って選ぶと意図せず全員分の情報同期が始まるので恐ろしいことになります)。[割り当てられたユーザーとグループのみを同期する]にすると、[ユーザーとグループ]で指定したユーザーとグループのみが自動同期されるため、こちらを選択しましょう。
なお、自動プロビジョニング対象とするユーザーの絞り込みには上記以外でもう一つ方法があり、それはスコープフィルターを使用してAzure ADのグループ名に特定の単語が入っていたら同期対象とする、といったような条件式での指定になります。
[プロビジョニングの編集]画面で、[マッピング]セクションを展開し、[Provision Azure Active Directory Groups]と[Provision Azure Active Directory Users]のそれぞれのリンクの中に[ソース オブジェクト スコープ]-[スコープフィルターの追加]メニューがあります。この画面で、特定グループだけを同期対象にするといった条件指定が出来るため、上手く指定をすれば、Azure Active Directory Premium P1のライセンスがなくても、特定グループや特定ユーザーのみの自動同期を行うことが可能です。
自動プロビジョニング対象とするユーザー属性の絞り込み
Azure ADからIAM Identity Centerに同期するユーザー情報には、名前以外にも所属部署や電話番号といった情報も含めることが出来ます。企業によっては認証に不要な情報をIDストアの外部に共有せず、最低限必須の情報だけを同期したいという要望もあるでしょう。
自動プロビジョニングの際、IAM Identity Centerにどのユーザー属性を同期するかは、[プロビジョニングの編集]画面で、[属性マッピング]を編集します。
IAM Identity Centerでは、[givenName], [surname], [userPrincipalName(=userName)], [displayName]が必須属性で、Azure AD側でユーザー名やその他の属性が変更された場合でもユーザーを識別できるように、[objectId(=externalId)]も必要とされます。
Automatic provisioning - AWS IAM Identity Center (successor to AWS Single Sign-On)
For SCIM synchronization to work, every user must have a First name, Last name, Username and Display name value specified. If any of these values are missing from a user, that user will not be provisioned.
Verify that the externalId SCIM mapping at your IdP corresponds to a value that is unique, always present, and least likely to change for your users. For example, your IdP might provide a guaranteed objectId or other identifier that’s not affected by changes to user attributes like name and email. If so, you can map that value to the SCIM externalId field. This ensures that your users won’t lose AWS entitlements, assignments, or permissions if you need to change their name or email.
Azure ADの推奨として、[IsSoftDeleted]も残すよう記載があるため、最低限6属性を残せば、Azure ADとIAM Identity Center間で自動プロビジョニングは機能することになります。裏を返すと、必須属性である[givenName], [surname], [userPrincipalName(=userName)], [displayName]が空(null)のユーザーがいると、そのユーザー情報は同期に失敗します。
IsSoftDeleted 属性を属性マッピングから削除することはお勧めしません。
全ての属性を削除する必要はない、デフォルトのマッピングから機能するのに必要な変更だけ行いたいという場合には、AWSのブログ記事にあるように[facsimileTelephoneNumber]と[mobile]属性を削除してください。なぜこの属性を削除するかというと、デフォルトでは、[telephoneNumber][facsimileTelephoneNumber][mobilephoneNumber]は全てIAM Identity Center側の[phoneNumber]にマッピングされるようになっており、複数の属性を一つの属性にマップすることが出来ないためエラーになるからです。
また、既に記載していますが、[externalId]属性には一意の値である[objectId]属性をマッピングする方が良いため、デフォルトのマッピングである[mailNickname]属性を変更して[objectId]属性にするのが良いでしょう。
AWS Single Sign-On の次の進化 | Amazon Web Services ブログ
属性マッピングを管理するページに移動します。そのセクションでは、facsimileTelephoneNumber および mobile 属性を使用しないため削除し、mailNickname 属性をクリックして編集し、Source 属性を objectId に変更します。
Remove the duplicate attributes. For example, having two different attributes being mapped from Azure AD both mapped to "phoneNumber_" on the AWS side would result in the error if both attributes have values in Azure AD. Only having one attribute mapped to a "phoneNumber__ " attribute would resolve the error.
SAMLとSCIMの構成完了後の設定
SAMLとSCIMの構成が完了したら、それ以降の設定は外部IDプロバイダーの場合もIdentity Center ディレクトリを利用する場合も変わりません。シングルサインオンをしたいログイン先のAWSアカウントと、対象ユーザー・グループ、AWSアカウントでそのユーザーに許可する権限を持ったアクセス権限セットの三者を紐づけることで、ユーザーは必要な権限でAWSアカウントにログインできるようになります。
まとめ
本記事では、Azure ADとIAM Identity CenterでSAMLによるシングルサインオンを構成する流れについて、世の中で既に説明がされているものに加えて、SAML認証対象ユーザーの絞り込み方や属性マッピングの取捨選択の理由など、なぜその操作が必要なのかという理由に深入りして説明しました。
企業のユーザー管理は歴史的にActive Directoryが強く、企業の既存資産を活用しようとすると、必然的にIAM Identity CenterとAzure ADを連携させる構成が多くなります。複数のクラウドに設定が分かれることでどちらのサポートに問い合わせても一貫した回答を得られないというお客様の事例を見たことがありますが、そうしたベンダー間の課題を埋めるためにIAM Identity CenterとAzure ADのSAML, SCIMの仕様に踏み込んでご説明しました。
より特殊な条件下での構成についても引き続き説明する予定ですが、本記事は長くなったため、より深い話は別記事でご説明します。
