シングル サインオン

Last reviewed 2023-02-27 UTC

シングル サインオン（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 に自動的にユーザーをプロビジョニングする外部の認証ソースと一緒によく使用されています。

注: 特権管理者の権限を持つユーザーは、シングル サインオンを迂回できます。これにより、SSO 構成が正しくない場合や、外部 IdP が使用できない場合でも、特権管理者はアカウントにアクセスできます。

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

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">[e-mail]</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/ がユーザー [e-mail] を認証したことが示されています。

   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 アカウントを構成できます。

注: 特権管理者は SSO を迂回できるため、外部 IdP によって適用される多要素認証はこれらのユーザーに適用されません。特権管理者のユーザーが保護されるように、これらのユーザーに 2 段階認証プロセスを有効にします。

ネットワーキング

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

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

外部 IdP の構成

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

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

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

注: SAML プロファイルを使用する場合、セキュリティ チャレンジを無効にすることはできません。組織内で携帯電話を持っていないユーザーがいる場合には、これが原因で問題が発生する可能性があります。SAML プロファイルの使用は、AD FS などの一部の IdP にも対応していません。

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

構成	従来の組織プロファイル に必要な設定	SAML プロファイル に必要な設定	備考
名前 ID	ユーザーのメインのメールアドレス	ユーザーのメインのメールアドレス
名前 ID の形式	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
エンティティ ID	ドメイン固有の発行元が有効になっている場合: google.com/a/DOMAIN ドメイン固有の発行元が無効になっている場合（デフォルト）: google.com 複数の Google Workspace アカウントまたは Cloud Identity アカウントを同じ IdP と統合する場合は、ドメイン固有の発行元を使用します。それ以外の場合は無効のままにします。	SAML プロファイルの一意のエンティティ ID。 エンティティ ID は、SAML プロファイルの作成日に応じて次のいずれかの形式を取ります。 https://accounts.google.com/samlrp/metadata?rpid=ID https://accounts.google.com/samlrp/ID
ACS の URL パターン（またはリダイレクト URL）	https://www.google.com/a/*	SAML プロファイルの一意の ACS URL。 URL は、SAML プロファイルの作成日に応じて次のいずれかの形式を取ります。 https://accounts.google.com/samlrp/acs?rpid=ID https://accounts.google.com/samlrp/ID/acs
リクエストの署名	オフ	オフ	Google ログインが発行する SAML 認証リクエストには署名されません。
アサーションの署名	オン	オン	Google ログインが信頼性を検証できるようにするには、SAML アサーションに署名する必要があります。 管理コンソールで SSO を設定するときに、トークン署名の鍵ペアの公開鍵をアップロードする必要があります。
アサーションの暗号化	オフ	オフ
署名アルゴリズム	RSA-SHA256	RSA-SHA256	RSA-SHA256 は RS256 と省略される場合もあります。

注: 使用している IdP によっては、名前が異なる場合があります。また、構成できない場合もあります。

次のステップ

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