ブログ

【AWS】Cognito SSO設定比較 〜Salesforceからのプロトコル〜

この記事をSNSでシェア!

はじめに

サービスを展開する際、既存システムのユーザー情報を利用してSSO(Single Sign-On)を行いたいというケースはよくありますよね。今回、「SalesforceをIdP(Identity Provider)、Amazon CognitoをSP(サービスプロバイダー)としてSSOを行いたい」という要件が案件の中で発生し、実際に技術検証を行いました。このSSO連携にはSAMLとOIDCの2つプロトコルが利用できますが、それぞれで仕様や手順が異なります。具体的な設定手順などは公式ドキュメントや先人の記事でいくつか存在するため、本記事では手順ではなく検証の中で判明した課題とその対応策についてご紹介できればと思います。

まず、SAMLとOIDCをそれぞれ簡単に紹介し、その後Cognitoで設定を行う際の注意点を紹介します。

SAML(Security Assertion Markup Language)

2005年に2.0が標準化された、業界標準となっている認証プロトコルです。多くの企業で採用実績があり、現在でも長く使用されています。
認証情報やメタデータがXMLベースで記載されているため、人手での実装やデバッグなどは少し行い辛いですが、煩雑な部分はCognitoが全て引き受けてくれます。

OIDC(OpenID Connect)

OIDCはOAuth 2.0の拡張として2014年に策定されたプロトコルです。JSON Web Token(JWT)形式でトークンを発行するため軽量で、デバッグなども行いやすく、新規アプリケーションではOIDCを利用することが推奨されています。モバイル・Web アプリとの相性も良く、近年はこちらが主流になりつつあります。


プロトコル比較

さて、それでは実際にそれぞれの認証プロトコルを利用してAWSへSSOを行う際の注意点を見ていきましょう。

SAML+Cognito

まずはSAMLを用いてSSO認証を行う際の注意点をご紹介します。SAMLを利用する際は、Salesforce側で証明書を発行し、メタデータをCognito側に連携する必要があります。連携方式として以下の2つの方法があります。

メタデータドキュメントをアップロード

Salesforceで発行されるメタデータドキュメントを、手動でCognitoへアップロードする方式です。発行されたXMLファイルを直接AWSへ連携します。基本的にIdPサービス事業者はこの方式をサポートしています。

メタデータドキュメントのエンドポイントURLを入力

Salesforceで発行されるメタデータドキュメント連携用エンドポイントURLを、Cognitoに設定する方式です。一度手動で設定した後は、証明書を更新しても自動で連携されます。メタデータのエンドポイントURLによる自動連携は便利な反面、全てのIdPサービス事業者が提供しているとは限りません。SalesforceではエンドポイントURLが発行されるため、こちらも利用することができます。

では、便利なエンドポイントURLによる自動連携を採用すべきでしょうか? 実は、必ずしもそうとは限りません。

Cognitoの公式ドキュメントには、メタデータの更新間隔は6時間ごとと明記されています。つまり、証明書情報をローテーションした場合反映されるまで最大で6時間かかる可能性があります。SalesforceのIdPに複数の証明書を並行して紐付けることができればローテーション中は並行運用が可能ですが、残念ながら紐付けることができる証明書は1つだけとなっています。

メタデータを手動アップロードする場合はすぐに反映されるため、Salesforceでの証明書更新→AWSへメタデータを手動アップロード、と一連の作業とすることで、ダウンタイムを最小限に抑えることができます。

証明書の更新作業は数年に1回の低頻度ではありますが、メンテナンスウィンドウの関係でどれだけのダウンタイムが許容できるかなど、運用負荷と相談しながらどちらの方式を利用するか検討すると良いでしょう。


OIDC+Cognito

次にOIDCを利用する際の注意点をご紹介します。OIDCではクライアントID、シークレットを利用して認証情報を確認します。Salesforceでは外部クライアントアプリケーションマネージャーからコンシューマー鍵(クライアントID)、コンシューマーの秘密(クライアントシークレット)という形で払い出されます。

IdP事業者によってはこのクライアントID、シークレットに有効期限を設定している場合もありますが、Salesforceでは有効期限はありません。認証情報のローテーションを行わない想定なら問題ありませんが、企業独自のセキュリティ要件によりローテーションを必須とする場合、ローテーション周期を独自で管理する必要があります。

また、Salesforce側で複数の外部クライアントアプリケーションを定義することが可能です。ローテーションを行う際は、SAMLとは異なり、旧クライアントと新クライアントを複数並行稼働させます。切り替えが完了したら、旧クライアントを削除することでダウンタイムを発生させない運用が可能です。


連携方式まとめ

方式メリットデメリット
SAML(手動アップロード)更新時に速やかに反映されるAWS側で毎回手動での作業が必要
SAML(URL自動連携)一度作業を行うとそれ以降はAWS側で手動での作業は不要反映まで最大で6時間かかる
OIDC有効期限がないため、一度作業を行うと更新が不要ローテーションを行う場合は複数のクライアントを作成する必要有

おわりに

本記事ではSalesforceをIdP、Amazon CognitoをSPとしてSSO設定を行う際のプロトコル毎の注意点を解説しました。

企業のセキュリティ要件や運用方針、保持している知見の違いによってSAML、OIDCどちらが良いと一口に言えるものではありません。しかし、証明書のローテーションで少なからずダウンタイムが発生するSAMLと比べ、OIDCを使用することでダウンタイムを発生させないことが可能ということは、導入の比較検討を行っている方にとって重要度の高い情報かと思います。OIDCは現在推奨されている方式ということもあり、特別な要件がなければOIDCを利用することをお勧めします。実際に私が担当している案件でも、以上の検証内容を踏まえOIDCを利用する方針で決定しています。

KYOSOでは実務や技術検証で培った知見を継続的に発信し、皆さんの業務効率化へ引き続き貢献していきます。

投稿者プロフィール

久保 研斗
久保 研斗
AWSをメインとするバックエンドエンジニア。要件定義から運用保守まで幅広く対応しています。趣味は競技プログラミングで、アルゴリズムやロジックのパフォーマンスチューニングが得意。
この記事をSNSでシェア!