はじめに

こんにちは。株式会社divxの山本です。
今回のテーマは、Microsoft Entra ID（旧Azure AD）を利用したSAML認証によるシングルサインオン（以下SSO）についてです。近年、SSOの需要は増加しており、日常的に利用している方も多いのではないかと思います。本記事では、SAML認証の仕組みを詳しく解説する中で、Amazon CognitoをIdPまたはSPとして使用する認証プロセスを掘り下げていきます。この記事が、SSOの導入や運用に携わる方々や、SSOに興味をお持ちの方にとって有益な情報となれば幸いです。

キーワード：Microsoft Entra ID、SAML、フェデレーション認証、SSO、Amazon Cognito、IDプロバイダー(IdP)

基本概念の説明

Microsoft Entra IDとは

Microsoft Entra IDは、クラウドベースのIDおよびアクセス管理（IAM）サービスであり、Microsoft Entraの一部として、以前はAzure Active Directory（Azure AD）として知られていました。組織や個人が複数のアプリケーションへのシームレスなアクセスを提供するために使用され、SAMLやOAuthなどの認証プロトコルをサポートしています。

SAMLとは

SAML（Security Assertion Markup Language）は、IDプロバイダー（IdP）とサービスプロバイダー（SP）の間で認証情報を安全に交換するためのXMLベースのプロトコル、およびフェデレーション認証のプロトコルの1つです。SAMLはエンタープライズ環境で広く使用されているSSOのプロトコルの一つであり、OAuthやOpenID Connectなどの他のプロトコルと共に利用されています。SAMLを利用することで、ユーザー認証の一元化が可能となり、これによりシステム全体の設計によってはパスワード管理やユーザーの追加・削除が効率化される場合があります。

一方、JSON形式の認証プロトコルと比較した場合、SAMLの設計は複雑であり、XMLベースのアプローチがアプリケーションのパフォーマンスに影響を与える可能性があることは理解されていますが、影響の程度は実装や使用状況によって異なるため、注意が必要です。

フェデレーション認証とは

フェデレーション認証は、SAMLやOAuthなどのプロトコルを使用して、複数の異なる認証システム間で信頼関係を確立し、一度の認証で複数のサービスにアクセスできる仕組みです。これにより、IdP（Identity Provider）がSP（Service Provider）に対して認証情報を提供し、ユーザーは再度認証する必要なくアクセスが許可されます。例えば、CognitoではSAMLプロトコルを使用してIDプロバイダー（IdP）とフェデレーションを確立することが可能です。具体的には、CognitoがSPとして機能し、外部のIdP（Microsoft Entra IDなど）によるユーザー認証を管理します。

SSOとは

SSO（シングルサインオン）は、一度の認証によって複数のアプリケーションにアクセスできる認証メカニズムです。企業のIT環境で特に重要であり、ユーザーエクスペリエンスを向上させるだけでなく、セキュリティの向上にも寄与します。

詳細な解説

一般的なSAML認証フロー

SAMLによるSSOの一般的なフローは以下の通りです。

1. ユーザーがサービスプロバイダー（SP）にアクセスを要求
2. SPがIdPに認証をリクエスト
   1. SPはSAMLリクエストを生成し、Microsoft Entra ID（IdP）に送信します。
3. ユーザーが認証を実行
   1. ユーザーはMicrosoft Entra IDでログインします。
4. IdPがSAMLレスポンスをSPに返す
   1. 認証が成功すると、IdPがSAMLレスポンスを生成し、SPに送信します。
5. SPがユーザーにアクセスを許可
   1. SPがSAMLレスポンスを検証し、ユーザーにアクセスを許可します。

フェデレーション認証の導入

CognitoをIdPまたはSPとして使用し、Microsoft Entra IDをIdPまたはSPとして設定することでフェデレーション認証を可能にします。

1. Microsoft Entra IDでエンタープライズアプリケーションを登録
   1. SAML統合のためのエンタープライズアプリケーションを作成し、Cognitoの情報を入力します。

2. CognitoでSAMLメタデータを設定したプロバイダーを作成

   1. エンドポイントURLや証明書情報が含まれるSAMLメタデータをMicrosoft Entra IDとCognitoの間で交換し、連携を確立します。

Microsoft Entra ID側にCognitoの情報を、Cognito側にMicrosoft Entra IDの情報を設定することで認証を強化します。

実装方法や活用例

では、3.1と3.2を実際の認証フローに当てはめて解説していきます。

実際の認証フロー

ステップ1　ユーザーがAppにアクセス
ステップ2　AppがCognitoにリダイレクト
ステップ3　CognitoがユーザーをMicrosoft Entra ID(SAML IdP)にリダイレクト
ステップ4　IdPがユーザーを認証
ステップ5　IdPがSAMLアサーションを生成
ステップ6　ユーザーがSAMLアサーションをCognitoに送信
ステップ7　CognitoがSAMLアサーションを検証
ステップ8　Cognitoがユーザーを認証し、セッションを確立
ステップ9　Appがユーザーをリダイレクト
ステップ10　ユーザーがAppにアクセス

フローの詳細解説

4.1の認証フローにおいて、特に重要となる部分はステップ3～7です。
これらのステップではSAML認証およびフェデレーション認証が行われる重要な部分になります。
各ステップの詳細解説を以下に記載します。

ステップ3　CognitoがユーザーをMicrosoft Entra ID(SAML IdP)にリダイレクト
Cognitoはユーザーがアクセスした際に、SAML IdPであるMicrosoft Entra IDにリダイレクトし、SAML認証を開始します。この際、CognitoはSAMLリクエストを生成し、HTTPリダイレクトまたはHTTP POSTバインディングを使用してMicrosoft Entra IDに渡します。

ステップ4　IdPがユーザーを認証
Microsoft Entra IDがユーザーの認証を行います。これはSAML認証の主要な部分であり、ユーザーの資格情報が確認されます。

ステップ5　IdPがSAMLアサーションを生成
Microsoft Entra IDが認証に成功すると、SAMLアサーション（認証や属性情報を含むデータのブロック）が生成されます。

※補足
ステップ3~5において、3.2で記載したMicrosoft Entra IDでのSAML認証用のアプリケーション作成と、CognitoでMicrosoft Entra IDをフェデレーションIdPとして利用するためのプロバイダーの作成が必要です。
Microsoft Entra IDで作成したSAML認証用のアプリケーションはCognitoからのSAMLリクエストを受け取り、ユーザー認証時に使用されます。
Cognitoでのプロバイダーの作成はMicrosoft Entra IDをフェデレーションIdPとして利用し、SAML認証を実行することを可能にします。

ステップ6　ユーザーがSAMLアサーションをCognitoに送信
SAMLアサーションはユーザーのブラウザを介してCognitoに返されます。この段階で、Cognitoはそのアサーションを検証します。

ステップ7　CognitoがSAMLアサーションを検証
Cognitoが受け取ったSAMLアサーションを検証し、認証が成功したかどうかを確認します。

このプロセス全体がフェデレーション認証に該当します。

実装時に直面した課題

Auth.federatedSignInメソッドとaws-exports.jsの設定

AmplifyのAuth.federatedSignInメソッドは、フェデレーション認証をトリガーするためのメソッドで、認証トークンの受け渡しや認証フローをスムーズに進行させるために使用されます。このメソッドは、これは、4.1のフローにおけるステップ3で使用されます。
このメソッドを活用するには、AWS Cognitoで外部のIdPとの連携設定を行う必要があり、加えてリダイレクトURIの設定をaws-exports.jsにも反映する必要があります。
実際に、Auth.federatedSignInメソッドが動作しなかった原因は、CognitoとローカルのリダイレクトURI設定に差異があったことにありました。この設定の不一致が原因で、認証フローの途中でエラーが発生し、ユーザーがMicrosoft Entra IDで認証を完了してもCognito側でその結果が適切に処理されず、アプリケーションに戻れないという問題が生じていました。しかし、aws-exports.jsのリダイレクトURI設定をCognitoと一致させることで、このエラーは解消され、SSOが正常に動作するようになりました。
aws-exports.jsの更新は、特にステージング環境や本番環境でSSOを構成する際に必要となる場合があります。環境ごとに異なるリダイレクトURIやSAML設定が必要であるため、Amplify CLI（amplify add authやamplify update authなど）を使用して、aws-exports.jsのoauthセクションや関連する設定部分を手動で更新する必要があります。
設定を最終的にamplify pushで反映すると、aws-exports.jsに加えAWS管理コンソール上の設定も上書きされます。そのため、更新する前にAWS管理コンソール上の設定内容とローカルの設定に差分がないかを慎重に確認することが重要です。

SSO時のテナント検証

Microsoft Entra IDは、AテナントやBテナントといったようにテナントごとに存在しています。Cognitoでそれぞれのテナントに対してプロバイダーを作成する場合、各テナントに対応するSAMLメタデータが必要なため、通常はテナントごとにプロバイダーを分け、認証を行うテナントを判別する必要があります。これにより、AテナントにはA用のプロバイダー、BテナントにはB用のプロバイダーが割り当てられる形になります。
ただし、複数のテナントにおいても、Microsoft Entra IDの特定のユースケースでは同一のプロバイダー設定を共有することも可能です。例えば、大規模な組織で親テナントが複数の子テナントを管理している場合や、関連性の高いテナント間で共通のプロバイダー設定を利用するケースなどです。一方で、1つのMicrosoft Entra ID（テナント）でSSOを検証している際に、同一のSAMLメタデータを含むプロバイダー設定が複数存在すると競合が発生する可能性があります。そのため、異なるプロバイダー設定による接続検証を行う場合には、追加でMicrosoft Entra IDのテナントを作成し、それを利用して検証する必要があります。

まとめ

Microsoft Entra IDを使用したSAML認証によるSSOは、広く使用されている認証手法の一つです。この実装により、企業はフェデレーション認証とSAML認証を連携させ、一元的なユーザー管理を実現できます。ユーザーは複数のアプリケーションに対して一度のログインでアクセスできるため、利便性が大幅に向上し、セキュリティリスクの軽減にも寄与します。
さらに、Cognitoなどのプラットフォームを活用することで、GoogleやAppleといった大手のプロバイダーに依存することなく、またはそれらと連携しながら、カスタム設定を行い柔軟に対応が可能です。このように、事前に認証フローを深く理解し、各設定がどのように連携するかを明確にすることで、顧客のニーズに合ったSSOソリューションを成功裏に実装できるでしょう。

おわりに

本記事では、Microsoft Entra IDを使用したSAML認証によるシングルサインオン（SSO）の基本概念と具体的な実装手法について詳しく解説しました。SAMLは特にエンタープライズ環境で広く採用されていますが、Amazon Cognitoは主にOAuth 2.0やOpenID Connectを使用しているため、SAMLとの直接的な組み合わせについては注意が必要です。

参考資料

Microsoft Entra IDの公式ドキュメント

シングル サインオン SAML プロトコルの公式ドキュメント

SAML設定 におけるAmazon Cognitoの公式ドキュメント

お悩みご相談ください