(もっと)IAM Identity CenterとAzure ADでシングルサインオン

目次
はじめに
IAM Identity Centerで必須の要求(クレーム)は何か
Azure ADゲストユーザーの扱いとSAMLクレームの複数の条件
- SAMLクレームの複数の条件
ユーザーの自動プロビジョニングの手動実行
Identity Centerディレクトリの利用
- パスワードポリシーが設定できない
- MFAの設定が可能
SAML証明書とSCIMアクセストークンの更新
まとめ

はじめに

※2022/07 AWS SSOがIAM Identity Centerに名称変更されたため、記事を加筆・修正

こちらの記事でAWS IAM Identity CenterとAzure ADでシングルサインオン構成を行う方法について、細かな補足を入れつつ説明しました。本記事はその中では書ききれなかったより複雑な条件での留意事項について説明します。

IAM Identity Centerで必須の要求(クレーム)は何か

SAMLを構成する場合、SAML認証時にIDプロバイダー(Azure AD)がサービスプロバイダー(IAM Identity Center)にユーザーの何の属性を渡してユーザー情報を確認させるかをクレームと呼びます。

Azure ADのエンタープライズアプリケーションを作成すると、デフォルトではシングルサインオンの[属性とクレーム]には、以下の情報を渡すようセットされています。

必要な要求：一意のユーザー識別子(nameidentifier)

追加の要求：name, givenname, surname, emailaddress

IAM Identity Centerでは、SAML認証時にユーザー情報の識別に使用するのは、[必要な要求]である一意のユーザー識別子のみです。Azure ADから渡されるユーザーのnameidentifierであるusernameが、IAM Identity Centerに登録されたユーザー名と一致すればSAML認証が行われます。

多くの場合、Azure ADではnameidentifierにはuserprincipalname=UPNが使用されますので、usernameにUPNを指定して自動プロビジョニングすれば一致するはずです。

なお、Azure AD側でログインのためにUPN以外の属性を使用している場合は、nameidentifierにUPN以外を指定するよう変更ください。後述しますが、Azure ADのログイン画面でUPNではなくメールアドレスを打ち込むケースだとUPNではなくメールアドレス(user.mail)を必要な要求に指定する必要があるかもしれません。(UPNがメールアドレスと同一の場合はUPNの指定で良い)

Troubleshooting IAM Identity Center issues - AWS IAM Identity Center (successor to AWS Single Sign-On)

The nameID value must exactly match the user name of an existing user in IAM Identity Center (it doesn’t matter if the email address in IAM Identity Center matches or not – the inbound match is based on username)

AWSサポートにも確認しましたが、IAM Identity Centerでは、追加の要求は不要のため、実施する必然性はありませんが、追加の要求をクレームから削除してもSAML認証は動作します。

また、この設定はあくまでSAMLのクレームに関わる設定であるため、自動プロビジョニングのSCIMとは関係がありません。こちらの設定で追加の要求であるemailaddress等を削除しても、自動プロビジョニングの方の属性でメールアドレスを同期するよう指定しておけば、問題なくユーザーはプロビジョニングされます。

Azure ADゲストユーザーの扱いとSAMLクレームの複数の条件

具体的なシステム現場での状況を想定しますが、IAM Identity CenterとAzure ADでシングルサインオンを構成して、ユーザー認証を一本化できたぞとなったときに、一つ問題が発生します。それは、外部ユーザーの存在です。

自社組織の人間であれば当然自社のAzure ADにユーザーIDを持っているでしょうが、外部ベンダーと委託契約をした場合などで、外部ベンダーの作業者は自社のAzure ADのユーザーIDを持っていません。

この状況では2通りの対応方法が考えられますが、一つはシングルサインオンのコンセプトを崩して、外部ベンダーの作業者用にIAMスイッチロールの仕組みを別途作成し、外部ベンダーの作業者はIAMの世界で作業してくださいと決めてしまうパターンです。(Azure ADに障害が発生してAWSアカウントにログインできなくなる可能性もあるため、どのみち緊急避難用のIAMスイッチロールの仕組みを準備しておく必要はいずれにしてもあるかもしれません。)

しかし、これでは夢がありませんので、今回はもう一つの方法を説明します。Azure ADはゲストユーザーとして外部ユーザーを招待することが出来ますので、外部ベンダーの作業者はゲストユーザーとして認証し、IAM Identity Centerにログインさせましょう。

SAMLクレームの複数の条件

ゲストユーザーをSAML認証させる際に問題になるのが、必要な要求の指定です。ゲストユーザーは自社ユーザーではありませんので、仮に自社ユーザーがUPNでログインしている場合、必要な要求はnameidentifierにUPNを指定すれば良いですが、外部ユーザーは一般的にメールアドレス情報で認証しますので、nameidentifierにUPNを指定していたらSAML認証が失敗します。nameidentifierにuser.mailを指定すればゲストユーザーは認証できるようになりますが、今度は自社ユーザーが認証できなくなります。

この問題を解決するには、必要な要求の編集を行い、一意のユーザー識別子の要求条件に複数の条件を持たせる設定を行います。メンバー(自社ユーザー)の場合はUPN、ゲストの場合はuser.mailをSAML認証時にIAM Identity Centerに渡してユーザー名と突合させるという条件を付けることが出来るため、どちらのユーザにも対処できるようになります。

ユーザーの自動プロビジョニングの手動実行

以上のようなゲストユーザーのSAMLの構成など、色々と設定変更を試行していると、既定の40分間隔ではなく、即座にユーザーをIAM Identity Centerに同期して認証テストをしてみたいということがあります。そのような場合は、Azure ADのプロビジョニングの画面で、[要求時にプロビジョニングする]を実行します。自動プロビジョニングしたいユーザー名を指定すると、対象ユーザーが即座に同期され、ユーザー属性の何が変更されたか確認できます。

これは、テスト目的でも有用ですし、例えば会社のVIPが新しくAzure ADにオンボードしてきて、ユーザー登録後すぐにシングルサインオン先のアプリケーションを使用したいので40分も待てない、というようなケースにも使用できます。

Identity Centerディレクトリの利用

ここまで外部IDプロバイダーはAzure ADである前提で話をしてきました。しかし、必ずしもすべての企業でAzure ADやOkta等のSaaS対応のIDプロバイダーは使用していないかもしれません。もちろん、オンプレミスでActive Directoryを運用しているなら、Azure Active Directory Connect(AADC)サービスを使用して、Azure ADにユーザー情報を同期しても良いかもしれませんが、ここでは前編の記事でご紹介したように、AWSでユーザー管理が完結するようローカルIDストアとしてIdentity Centerディレクトリにユーザーを一から登録して運用するパターンを考えてみます。

パスワードポリシーが設定できない

Identity Centerディレクトリは無償で使えるディレクトリサービスにはなりますが、企業で使用する際にネックになるのが、ユーザーのパスワードポリシーを指定できない点です。企業では業界のセキュリティ基準などで何文字以上で何回パスワード入力を間違えたらロックする、といった指定を細かにされることが多いですが、Identity Centerディレクトリは以下の製品要件以外のポリシーを指定できず、何回入力失敗したらロックするということもできません。

Passwords are case-sensitive.
Passwords must be between 8 and 64 characters in length.
Passwords must contain at least one character from each of the following four categories: Lowercase letters (a-z), Uppercase letters (A-Z), Numbers (0-9), Non-alphanumeric characters (~!@#$%^&*_-+=`|(){}[]:;"'<>,.?/)
The last three passwords cannot be reused.

Password requirements when managing identities in IAM Identity Center - AWS IAM Identity Center (successor to AWS Single Sign-On)

そういったきめ細かいポリシーを設定する必要がある場合は、専用機能を作りこんでいるAzure ADのようなサービスを利用するか、代替措置を何かしら行うことを約束するかという判断が必要です。

AWSとして、AWS SSOをIAM Identity Centerに改称してより推進していくのであろうと考えられますので、パスワードポリシーのきめ細かな設定については実装されることを期待しています。

MFAの設定が可能

一方で、Identity CenterディレクトリはMFA(多要素認証・二段階認証)の構成を行うことが出来ますので、これは有用です。設定により、メールでVerification Codeを送付する二段階認証や、認証アプリ等での二要素認証を設定できるのは柔軟性があります。

SAML証明書とSCIMアクセストークンの更新

最後に、SAMLでのシングルサインオンを構成した後に、運用の中で発生する作業を挙げます。SAMLを構成した際に交換したメタデータには証明書が含まれていましたが、この証明書にも有効期限は存在します。また、SCIMの設定をした際にアクセストークンをIAM Identity Center側で作成しましたが、アクセストークンにも有効期限が存在します。

一度シングルサインオンを構成したら後は安心と思っていると、数年後に突然シングルサインオンが出来なくなって利用者から障害問い合わせが発生するかもしれません。SAMLを構成するための証明書やSCIM用のアクセストークンは、有効期限が迫ってきたら新しい証明書やアクセストークンを生成して、更新作業を行う必要があります。

詳細は下記記事にてまとめられていますので、参照ください。

Azure AD における SAML 署名証明書を更新する | Japan Azure Identity Support Blog

Automatic provisioning - AWS IAM Identity Center (successor to AWS Single Sign-On)