シングル サインオン（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 コンソールにアクセスした場合のプロセスの例を示しています。
- ブラウザで Google Cloud コンソール（または認証が必要な他の Google リソース）を表示します。
- まだ認証されていないため、Google Cloud コンソールはブラウザを Google ログインにリダイレクトします。
- Google ログインからログインページが返され、メールアドレスの入力を求められます。
- メールアドレスを入力してフォームを送信します。
- Google ログインは、メールアドレスに関連付けられている Cloud Identity アカウントまたは Google Workspace アカウントを検索します。
関連付けられている 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 の交換が続行します。
外部 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 認証リクエストの発行元と一致）に対して発行され、IdPhttps://idp.example.org/がユーザーbob@example.orgを認証したことが示されています。SAML アサーションにはデジタル署名も含まれています。IdP は、署名証明書の秘密鍵を使用してこの署名を作成します。秘密鍵を知っているのは IdP だけです。対応する公開鍵は Cloud Identity または Google Workspace の SSO 構成に含まれ、Google ログインと共有されます。
SAML アサーションには、SAML サービス プロバイダがアサーションの信頼性を検証するためのデジタル署名も含まれています。
ブラウザが SAML アサーションを Google ACS エンドポイントに送信します。
ACS エンドポイントが SAML アサーションのデジタル署名を検証します。このチェックは、アサーションが信頼できる外部 IdP から送信され、改ざんされていないことを確認するために行われます。署名が有効であれば、ACS エンドポイントはアサーションの内容を分析します（オーディエンス情報の検証や
NameID属性の読み取りなどを行います）。ACS エンドポイントが SAML アサーションの
NameIDをユーザーのメインのメールアドレスと照合し、ユーザー アカウントを検索します。エンドポイントがセッションを開始します。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 つの方法があります。
- 外部 IdP が多要素認証をサポートしている場合は、SAML ベースのログイン プロセスで多要素認証を実行できます。この場合、Cloud Identity または Google Workspace に追加の構成は必要ありません。
- 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 プロファイルはどれかを決定します。
従来の組織の SSO プロファイル: 単一の組織プロファイルを作成して、単一の IdP と統合できます。Cloud Identity アカウントまたは Google Workspace アカウントのユーザー、グループ、組織部門ごとに、SSO を使用する必要があるかどうかを判断します。
IdP を構成する正しい方法は、SAML プロファイルと従来の組織プロファイルのどちらを使用するかによって異なります。次の表に、互換性を維持するために、外部 IdP で構成する必要がある設定を示します。
| 構成 | 従来の組織プロファイル に必要な設定 |
SAML プロファイル に必要な設定 |
備考 |
|---|---|---|---|
| 名前 ID | ユーザーのメインのメールアドレス | ユーザーのメインのメールアドレス | |
| 名前 ID の形式 | urn:oasis:names:tc:SAML:1.1: |
urn:oasis:names:tc:SAML:1.1: |
|
| エンティティ ID |
ドメイン固有の発行元が有効になっている場合:
ドメイン固有の発行元が無効になっている場合（デフォルト）:
複数の Google Workspace アカウントまたは Cloud Identity アカウントを同じ IdP と統合する場合は、ドメイン固有の発行元を使用します。それ以外の場合は無効のままにします。 |
SAML プロファイルの一意のエンティティ ID。 エンティティ ID は、SAML プロファイルの作成日に応じて次のいずれかの形式を取ります。
|
|
| ACS の URL パターン（またはリダイレクト URL） | https://www.google.com/a/* |
SAML プロファイルの一意の ACS URL。 URL は、SAML プロファイルの作成日に応じて次のいずれかの形式を取ります。
|
|
| リクエストの署名 | オフ | オフ | Google ログインが発行する SAML 認証リクエストには署名されません。 |
| アサーションの署名 | オン | オン | Google ログインが信頼性を検証できるようにするには、SAML アサーションに署名する必要があります。 管理コンソールで SSO を設定するときに、トークン署名の鍵ペアの公開鍵をアップロードする必要があります。 |
| アサーションの暗号化 | オフ | オフ | |
| 署名アルゴリズム | RSA-SHA256 | RSA-SHA256 | RSA-SHA256 は RS256 と省略される場合もあります。 |
次のステップ
- 外部 IdP と統合するためのリファレンス アーキテクチャを確認する。
- Azure AD または Active Directory でアカウントのプロビジョニングと SSO を設定する方法を学習する。
- 外部 IdP と Google Cloud を連携するためのベスト プラクティスを確認する。