Looker（Google Cloud コア）ユーザー認証に Workforce Identity 連携を使用する

Workforce Identity 連携を使用すると、外部 ID プロバイダ（IdP）を使用して Looker（Google Cloud コア）インスタンスに対するユーザーとユーザー グループの認証を行うことができます。Workforce Identity 連携を使用すると、組織内のユーザーはシングル サインオン（SSO）を使用して Looker（Google Cloud コア）にアクセスできます。ユーザーごとに Google アカウント（Cloud Identity アカウントまたは Google Workspace アカウント）をプロビジョニングまたは同期する必要はありません。

Workforce Identity 連携は、OpenID Connect （OIDC）または SAML 2.0 を使用する外部 IdP（Microsoft Entra ID（旧 Azure AD）、Okta、PingIdentity など）をサポートしています。

機能プレビュー期間中は、パブリック セキュア接続を使用する Looker（Google Cloud コア）インスタンスのみがサポートされます。

Workforce Identity 連携と Looker（Google Cloud コア）の連携の仕組み

Looker（Google Cloud コア）インスタンスの Workforce Identity 連携を構成すると、次のプロセスが行われます。

  1. 認証: ユーザーが Looker（Google Cloud コア）インスタンスの URL に移動します。[ログインページをバイパス] 設定が有効になっている場合、ユーザーは サインイン ポータル Google Cloud （https://auth.cloud.google/authorize）に自動的にリダイレクトされ、そこから認証のために外部 IdP にリダイレクトされます。
  2. トークン交換: ユーザーが IdP で認証されると、IdP は認証アサーションを Google Cloud Security Token Service （STS）に返します。STS は、アサーションを連携アクセス トークンと ID トークンに交換します。
  3. 認可: Looker（Google Cloud コア）は、連携プリンシパルがインスタンスに対する必要な Identity and Access Management（IAM）権限（looker.instances.login）を持っていることを確認します。
  4. プロビジョニングとロールの割り当て: Looker（Google Cloud コア）は、最初のログイン時にユーザー アカウントを作成し（ジャストインタイム プロビジョニング）、IdP から受信したクレームに基づいてグループからロールへのマッピングとユーザー属性を適用します。

始める前に

Looker（Google Cloud コア）の Workforce Identity 連携を構成する前に、次のロールと構成があることを確認してください。

必要な IAM のロール

Workforce Identity 連携を構成して Looker（Google Cloud コア）インスタンスを作成するには、次のロールが必要です。

必要な API

プロジェクト Google Cloud で次の API を有効にします。

ステップ 1: Workforce Identity プールとプロバイダを設定する

Workforce Identity プールとプロバイダは、プロジェクト レベルではなく Google Cloud 組織レベルで作成されます。

Workforce Identity プールとプロバイダを設定する手順は次のとおりです。

  1. Workforce Identity 連携を構成する のドキュメント ページの手順に沿って、Workforce Identity プールを作成します。
  2. OIDC または SAML 2.0 IdP の Workforce Identity プール プロバイダを作成します。
    • OIDC プロバイダの場合は、OIDC Workforce Identity 連携を構成するをご覧ください。
    • SAML プロバイダの場合は、SAML 2.0 Workforce Identity 連携を構成するをご覧ください。
    • プロバイダの作成時に、次の属性マッピングをすぐに定義します。
      • メール: IdP のメール クレームを google.email にマッピングします。このマッピングはユーザーの識別に必須 です。このマッピングがないと認証に失敗します。
      • 姓と名: IdP の名と姓のクレームを attribute.given_name（名）と attribute.family_name（姓）にマッピングします。これらのマッピングは、Looker ユーザー プロファイルにデータを入力するために必須 です。このマッピングがないと認証に失敗します。

  3. 必要に応じて、次の属性マッピングも構成します。

    • グループ: IdP のグループ クレーム（assertion.groups など）を google.groups にマッピングします。グループのミラーリングを有効にして、IdP グループを Looker のロールにマッピングする場合は、このマッピングが必要です。OIDC プロバイダの場合は、IdP で必要な場合は、プロバイダ構成で the groups スコープもリクエストするようにしてください（ IdP 固有の要件に合わせて Workforce Identity 連携を構成する をご覧ください）。
    • カスタム属性: カスタム IdP クレーム を attribute.<attribute_name> にマッピングします。Looker（Google Cloud コア）でこれらのマッピングされた属性を使用して、データベース接続をパラメータ化し、行レベルのデータアクセス フィルタを適用できます。

セッション継続時間とバックグラウンド同期を構成する

ブラウザ セッション、長時間実行されるスケジュールされた配信、ユーザー API キーアクセス、コネクタ統合を中断なくサポートするには、次の操作を行います。

  1. Workforce プール プロバイダでバックグラウンド属性の同期を構成します。これにより、 Google Cloud ユーザー属性と グループ メンバーシップをバックグラウンドで定期的に更新できます:
    • OIDC プロバイダの場合: OIDC 認可コード フローを offline_access スコープ（更新トークンを使用してユーザー属性とグループ メンバーシップを 定期的に更新する）または SCIM 2.0 プロビジョニングを使用して構成します。 ユーザーが OIDC トークン サイズの上限を超える多数のグループに属している場合は、SCIM 2.0 プロビジョニングを構成してグループ メンバーシップを Google Cloudに同期します。
    • SAML プロバイダの場合: Workforce プール プロバイダで SCIM 2.0 プロビジョニング を構成します。SAML アサーションは更新トークンをネイティブに提供しないため、オフラインのスケジュールされた配信とアラートを有効にするには SCIM 2.0 が必要です。

  2. Access Context Manager クラウド バインディングを使用して、Workforce プールの セッション継続時間ポリシー を構成し、 ポリシーを 90 日（7,776,000 秒）に設定します。

    このポリシーでは、最大セッション継続時間と更新トークンの有効期間が 90 日に設定されます。セッション継続時間ポリシーが構成されていない場合や、短い期間に設定されている場合、Workforce プールの更新トークンの有効期間が Looker のセッション継続時間の設定よりも優先されます。更新トークンの有効期限が切れると、ブラウザ セッション、オフライン スケジュール、ユーザー API キー、接続されたアプリケーションで再認証が必要になります。

ステップ 2: Workforce プリンシパルに IAM 権限を付与する

Workforce ユーザーが Looker（Google Cloud コア）インスタンスにログインできるようにするには、Workforce プリンシパルまたはグループに Looker インスタンス ユーザー（roles/looker.instanceUser）または Looker 管理者（roles/looker.admin）の IAM ロールを付与します。

次のプリンシパル ID を使用して、個々のユーザー、グループ全体、または Workforce プール内のすべてのプリンシパルにロールを付与できます。

  • 単一の Workforce ユーザー: 

    principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_ID

  • Workforce グループ: 

    principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID

  • Workforce プール内のすべてのプリンシパル: 

    principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/*

IAM ロールの割り当ての詳細については、 IAM を使用した Looker（Google Cloud コア）のアクセス制御の ドキュメント ページをご覧ください。

ステップ 3: Workforce Identity 連携をプライマリ認証方法として選択する

Workforce Identity 連携は、新しい Looker（Google Cloud コア）インスタンスを作成するときにプライマリ認証方法として選択するか、既存のインスタンスを編集して選択できます。

インスタンスの作成時

新しい Looker（Google Cloud コア）インスタンスを作成するときに、Workforce Identity 連携をプライマリ認証方法として選択できます。

Console

  1. Google Cloud コンソールで [Looker（Google Cloud コア）] ページに移動します。

    Looker（Google Cloud コア）に移動

  2. [インスタンスを作成] をクリックします。
  3. パブリック セキュア接続、Private Service Connect 接続、プライベート サービス アクセス接続を使用するインスタンスの作成のドキュメントの 説明に沿って、インスタンス名、リージョン、エディションの構成を完了します。
  4. [認証] セクションで、プライマリ認証方法として [Workforce Identity 連携（SAML/OIDC）] を選択します。
  5. [作成] をクリックします。

OAuth をセカンダリ認証方法として設定するには、インスタンスの作成後にインスタンス構成を編集します。

既存のインスタンスを編集する場合

既存の Looker（Google Cloud コア）インスタンスがある場合は、インスタンス構成を編集して Workforce Identity 連携をプライマリ認証方法として選択するか、OAuth をセカンダリ認証方法として設定できます。

Console

  1. Google Cloud コンソールで [Looker（Google Cloud コア）] ページに移動します。

    Looker（Google Cloud コア）に移動

  2. 編集するインスタンスの名前をクリックします。
  3. インスタンスの [詳細] タブで、[編集] をクリックします。
  4. [認証] セクションで、プライマリ認証方法として [Workforce Identity 連携（SAML/OIDC）] を選択します。
  5. （省略可）OAuth をセカンダリ認証方法として許可するには、[セカンダリ OAuth を有効にする] 切り替えを有効にします。
  6. [保存] をクリックします。

ステップ 4: Looker で Workforce Identity の設定を構成する

Looker（Google Cloud コア）インスタンスが作成されたら、管理者は Looker 管理パネルの [Workforce 認証] ページで、ユーザー属性のマッピング、グループのミラーリング、ログイン オプションを構成できます。

  1. 管理者 Looker ロールを持つアカウントで Looker（Google Cloud コア）インスタンスにログインします。
  2. 左側のナビゲーション メニューで、[管理] > [認証] > [Workforce Identity] を選択します。
  3. 次のセクションで説明する設定を構成します。

次の設定の詳細については、[**Workforce 認証**] ページのドキュメントをご覧ください。

ユーザー アカウントを統合する

[次を使用してユーザーを統合] フィールドで、ユーザーが Workforce Identity 連携で初めてログインしたときに、既存のユーザー アカウントを統合する認証システムを選択します。

統合でサポートされているシステムは次のとおりです。

  • Google
  • SAML
  • OIDC

ログインページをバイパスする

[ログインページをバイパス] オプションは、認証されていないユーザーを企業の SSO ポータルに自動的にリダイレクトするかどうかを制御します。

  • 有効（デフォルト）: ユーザーがインスタンスの URL に移動すると、Looker のログインページが表示されずに、IdP のログイン画面に自動的にリダイレクトされます。
  • 無効: ユーザーに Looker のログインページが表示され、使用可能な認証オプションを選択できます。

[構成を保存] をクリックして設定を適用します。

ユーザー属性のマッピング

IdP アサーションのクレームを Looker ユーザー属性にマッピングします。 ユーザー属性は、データベース接続のパラメータ化や行レベルのセキュリティ フィルタの適用など、さまざまな用途に使用できます。

  • [**属性のマッピング**] セクションで、Google Workforce 属性を 対応する Looker ユーザー属性にマッピングします（たとえば、 attribute.department を department ユーザー属性に マッピングします）。

グループとロール

ユーザーロールは、グループのミラーリングまたはデフォルトのロール割り当てによって管理できます。

  • IdP からグループをミラーリングする: この設定を有効にすると、Looker（Google Cloud コア）は、IdP トークン アサーションで渡されたグループをミラーリングする Looker グループを作成します。
    • [グループ マッピング] テーブルで、外部 IdP グループ名を Looker グループにマッピングし、適切な Looker ロール（閲覧者、ユーザー、デベロッパーなど）を割り当てます。
  • 新規ユーザーのデフォルト ロール: グループのミラーリングが使用されていない場合や、ユーザーと一致しない場合は、最初のログイン時に新規ユーザーに付与するデフォルトのロールを指定します。
  • 新規ユーザーのデフォルト グループ: グループのミラーリングが使用されていない場合や、ユーザーと一致しない場合は、新規ユーザーに割り当てるデフォルトのグループを指定します。

セッション管理とトークンの有効性

Looker（Google Cloud コア）のユーザー セッションとトークンは、Workforce Identity プールポリシー（セッション継続時間ポリシーなど）で構成されたセッション継続時間と更新トークンの有効期間に則って管理されます。

  • ブラウザ セッション: Looker セッション継続時間の設定 では、永続セッションを使用する場合、最大 30 日間のセッションがサポートされます。 ただし、Workforce Identity プールの有効期間が Looker で構成されたセッション継続時間よりも短い場合は、更新トークンの有効期間が優先されます。更新トークンの有効期限が切れると、ユーザーは再度ログインする必要があります。セッション継続時間ポリシーで 90 日間の更新トークンの有効期間を設定することをおすすめします。
  • スケジュールされた配信とアラート（オフライン ジョブ）: スケジュールのオーナーが有効な IdP トークンを持っている限り、バックグラウンド ジョブは実行されます。スケジュールまたはアラートの作成者が 90 日以上（または Workforce プール セッション ポリシーで構成された期間）インスタンスにログインしない場合、オフライン セッションの有効期限が切れ、そのユーザーが所有するスケジュールされた配信またはアラートは一時停止されます。一時停止したスケジュールまたはアラートを再開するには、オーナーがインスタンスにログインするか、管理者がスケジュールの所有権を割り当てる必要があります。
  • Looker OAuth サーバーとコネクタ: Looker OAuth サーバーを使用する統合（データポータル、コネクテッド シート、サードパーティ コネクタなど）では、30 日間の更新トークン（またはデータポータルの有効期限のない更新トークン）が使用されます。Workforce プール セッションの継続時間が 90 日未満に設定されている場合、セッション継続時間の有効期限が切れると、Looker で再認証が必要になることがあります。
  • ユーザー API キー: ユーザー API キーによって生成された API アクセス トークンは 1 時間有効で、有効なユーザー IdP セッションが必要です。ユーザーの IdP セッションの有効期限が切れた場合（90 日ごと、または Workforce プール セッションの継続時間に基づく）、API キーを引き続き使用するには、ユーザーがインスタンスに再度ログインする必要があります。
  • サービス アカウント API キー: サービス アカウント API アクセス トークンは、Workforce プール セッション ポリシーの影響を受けません。

次のステップ