シングル サインオン

シングル サインオン（SSO）を使用するように Cloud Identity または Google Workspace のアカウントを構成できます。SSO を有効にすると、ユーザーが Google サービスにアクセスする際にパスワードの入力を求めるメッセージが表示されません。代わりに、外部 ID プロバイダ（IdP）にリダイレクトされます。

SSO を使用すると、次のような利点があります。

• ユーザーは、既存の認証情報を使用して認証を行うことができます。認証情報を頻繁に入力する必要がないため、ユーザー エクスペリエンスが向上します。
• 既存の IdP が、ユーザーの認証に使用する記録システムを維持します。
• パスワードを Cloud Identity や Google Workspace に同期する必要はありません。

SSO を使用するには、Cloud Identity または Google Workspace のユーザー アカウントとそれに対応する外部 IdP の ID が必要になります。このため、SSO は Cloud Identity または Google Workspace に自動的にユーザーをプロビジョニングする外部の認証ソースと一緒によく使用されています。

シングル サインオン プロセス

Cloud Identity と Google Workspace は、シングル サインオンで Security Assertion Markup Language（SAML）2.0 をサポートしています。SAML は、SAML IdP と SAML サービス プロバイダの間で認証と認可のデータを交換するためのオープン標準です。Cloud Identity または Google Workspace に SSO を使用する場合、外部 IdP は SAML IdP で、Google は SAML サービス プロバイダになります。

Google は SAML 2.0 HTTP POST バインディングを実装しています。このバインディングでは、SAML IdP と SAML サービス プロバイダの間で認証情報の交換方法を指定します。次の図は、SSO を使用して Google Cloud コンソールにアクセスした場合の、このプロセスの動作の一例を示しています。

1. ブラウザで Google Cloud コンソール（または認証が必要な他の Google リソース）を表示します。
2. まだ認証されていないため、 Google Cloud コンソールはブラウザを Google ログインにリダイレクトします。
3. Google ログインからログインページが返され、メールアドレスの入力を求められます。
4. メールアドレスを入力してフォームを送信します。
5. Google ログインは、メールアドレスに関連付けられている Cloud Identity アカウントまたは Google Workspace アカウントを検索します。

6. 関連付けられている Cloud Identity または Google Workspace のアカウントでシングル サインオンが有効になっているため、ブラウザは構成済みの外部 IdP の URL にリダイレクトされます。リダイレクトの前に、URL に 2 つのパラメータ（RelayState と SAMLRequest）が追加されます。

   • RelayState には、外部 IdP が後で返す識別子が含まれています。

   • SAMLRequest には SAML 認証リクエストが含まれています。これは、デフレートされた base64 エンコードの XML ドキュメントで、URL がエンコードされています。デコードされた SAML 認証リクエストは次のようになります。

     <samlp:AuthnRequest
             ProviderName="google.com"
             IsPassive="false"
             AssertionConsumerServiceURL="https://www.google.com/a/example.com/acs"
             ...>
       <saml:Issuer xmlns:saml="...">google.com</saml:Issuer>
       <samlp:NameIDPolicy
             AllowCreate="true"
             Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
     </samlp:AuthnRequest>
     

   このリクエストの例は、外部 IdP にユーザーの認証を依頼し、オーディエンス google.com に SAML アサーションを作成して、https://www.google.com/a/example.com/acs の Assertion Consumer Service（ACS）に送信しています。

   ACS URL（example.com）に埋め込まれているドメインは、Google Workspace または Cloud Identity アカウントのプライマリ ドメインに対応しています。

   SSO を構成するときにドメイン固有の発行元を使用すると、発行元は google.com ではなく google.com/a/DOMAIN になります。ここで、DOMAIN は Cloud Identity または Google Workspace アカウントのプライマリ ドメインです。

   外部 IdP の認証手順は IdP とその構成によって異なります。たとえば、ログイン ダイアログが表示される場合もあれば、MFA またはフィンガープリントを要求するプロンプトが表示される場合もあります。これらのステップが正常に完了すると、SAML の交換が続行します。

   

7. 外部 IdP が特別に作成された HTML ページを返します。これにより、ブラウザは ACS URL に HTTP POST リクエストをすぐに送信します。このリクエストには 2 つのパラメータがあります。

   • RelayState: SAML 認証リクエストで最初に IdP に渡された値が含まれます。

   • SAMLResponse: base64 エンコードの SAML アサーションが含まれます。SAML アサーションは、IdP によってユーザーが正常に認証されたことを示す XML ドキュメントです。デコードされた SAML アサーションは次のようになります。

     <samlp:Response ...>
       ...
       <Assertion x...>
         <Issuer>https://idp.example.org/</Issuer>
         <Signature ...>
           ...
         </Signature>
         <Subject>
           <NameID Format="...:nameid-format:emailAddress">bob@example.org</NameID>
           ...
         </Subject>
         <Conditions NotBefore="..." NotOnOrAfter="...">
           <AudienceRestriction>
             <Audience>google.com</Audience>
           </AudienceRestriction>
         </Conditions>
         <AttributeStatement>
           ...
         </AttributeStatement>
         <AuthnStatement AuthnInstant="..." ...>
           <AuthnContext>
             <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
           </AuthnContext>
         </AuthnStatement>
       </Assertion>
     </samlp:Response>
     

   このサンプル アサーションは、オーディエンス google.com（SAML 認証リクエストの発行元と一致）に対して発行され、IdP https://idp.example.org/ がユーザー bob@example.org を認証したことが示されています。

   SAML アサーションにはデジタル署名も含まれています。IdP は、署名証明書の秘密鍵を使用してこの署名を作成します。秘密鍵を知っているのは IdP だけです。対応する公開鍵は Cloud Identity または Google Workspace の SSO 構成に含まれ、Google ログインと共有されます。

   SAML アサーションには、SAML サービス プロバイダがアサーションの信頼性を検証するためのデジタル署名も含まれています。

8. ブラウザが SAML アサーションを Google ACS エンドポイントに送信します。

9. ACS エンドポイントが SAML アサーションのデジタル署名を検証します。このチェックは、アサーションが信頼できる外部 IdP から送信され、改ざんされていないことを確認するために行われます。署名が有効であれば、ACS エンドポイントはアサーションの内容を分析します（オーディエンス情報の検証や NameID 属性の読み取りなどを行います）。

10. ACS エンドポイントが SAML アサーションの NameID をユーザーのメインのメールアドレスと照合し、ユーザー アカウントを検索します。エンドポイントがセッションを開始します。

11. RelayState パラメータでエンコードされた情報に基づいてエンドポイントは最初にアクセスするリソースの URL を特定し、 Google Cloud コンソールにリダイレクトされます。

IdP を起点とするログイン

前のセクションで説明したプロセスは、サービス プロバイダによって開始されることから、「サービス プロバイダを起点とするログイン」といわれることもあります。上の例で、 Google Cloud コンソールが起点となっています。

SAML では「IdP を起点とするログイン」という別のフローも定義されています。このフローは IdP から始まります。Google では、このフローをサポートしていませんが、次の URL を使用してサービス プロバイダを起点とするログインを開始すると、同様の結果が得られます。

https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://console.cloud.google.com/

この例では、DOMAIN は Cloud Identity または Google Workspace アカウントのプライマリ ドメインです。

多要素認証

ユーザー アカウントを不正アクセスから保護するために、認証時に 2 つ目の要素の提供をユーザーに求めることもできます。シングル サインオンで多要素認証を実装するには、次の 2 つの方法があります。

1. 外部 IdP が多要素認証をサポートしている場合は、SAML ベースのログイン プロセスで多要素認証を実行できます。この場合、Cloud Identity または Google Workspace に追加の構成は必要ありません。
2. IdP が多要素認証をサポートしていない場合は、外部 IdP でユーザーが認証された直後に 2 段階認証プロセスを実行するように Cloud Identity または Google Workspace アカウントを構成できます。

ネットワーキング

SAML 2.0 HTTP リダイレクト バインディングでは、IdP とサービス プロバイダは直接通信を行いません。次の図に示すように、すべての通信はユーザーのブラウザを介して中継されます。

このアーキテクチャでは、インターネット経由で会社のネットワークにアクセスできるなら、IdP をインターネット経由で公開する必要はありません。また、IdP がインターネットにアクセスする必要もありません。

外部 IdP の構成

Cloud Identity と Google Workspace では、次の機能を使用してシングル サインオンを構成できます。

• SAML プロファイル: 統合する IdP ごとに SAML プロファイルを作成できます。次に、Cloud Identity アカウントまたは Google Workspace アカウントのユーザー、グループ、組織部門ごとに、SSO を使用するかどうか、使用する必要がある SAML プロファイルはどれかを決定します。

• 以前の SAML プロファイル（以前は組織の SSO プロファイルと呼ばれていました）: 以前の SAML プロファイルを使用して、単一の IdP と統合できます。Cloud Identity アカウントまたは Google Workspace アカウントのユーザー、グループ、組織部門ごとに、SSO を使用する必要があるかどうかを判断します。

IdP を構成する正しい方法は、SAML プロファイルと以前の SAML プロファイルのどちらを使用するかによって異なります。次の表に、互換性を維持するために、外部 IdP で構成する必要がある設定を示します。

次のステップ

• 外部 IdP と統合するためのリファレンス アーキテクチャを確認する。
• Microsoft Entra ID または Active Directory でアカウントのプロビジョニングと SSO を設定する方法を学習する。
• Google Cloud と外部 IdP の連携に関するベスト プラクティスを確認する。

寄稿者

著者: Johannes Passing | クラウド ソリューション アーキテクト